Method for communication between processor of vehicle, computing device, and vehicle

Abstract

Embodiments of the present disclosure provide a method for communication between processors of a vehicle. The processor comprises an MCU and an SoC which are connected with each other, and the first virtual machine and the second virtual machine run on the SoC. The method comprises the following steps: establishing corresponding communication connection with a first virtual machine, a second virtual machine and an MCU (Microprogrammed Control Unit); sending a communication protocol file to the first virtual machine, the second virtual machine and the MCU to indicate a message template followed by mutual communication; receiving a communication message from at least one of the first virtual machine, the second virtual machine and the MCU via the corresponding communication connection; determining a target party of the communication message based on the communication protocol file; and when the target party comprises one or more objects in the first virtual machine, the second virtual machine and the MCU, sending a communication message to the one or more objects through the established corresponding communication connection. According to the method, any direct interaction between the plurality of virtual machines and the MCU on the SoC can be realized, the timeliness of mutual communication is effectively ensured, and overhigh maintenance manpower and time cost is avoided.

Description

Technical Field

[0001] The present disclosure relates to the field of communication, and more particularly to a method for communication between processors of a vehicle, a system-level processor, a computing device or an in-vehicle system, a computer-readable storage medium, a computer program product, and a vehicle. Background Art

[0002] With the development of motor vehicles, it has evolved from the initial fuel-driven four-wheel to the current in-vehicle system (for example, intelligent entertainment control system, etc.), and the chip or processor responsible for computing or control has also evolved from the initial microprocessor or microcontroller (MCU) to the current MCU + system-level processor or chip (SOC) (for example, SoC includes CPU core module, digital signal processor DSP module, memory module, communication interface module). On the one hand, with the continuous advancement of sensors, artificial intelligence, image processing, voice recognition, in-vehicle operating system and communication technology, vehicles are moving towards intelligence and networking. For example, the integrated experience represented by the smart cockpit, such as "in-vehicle infotainment system + streaming media rearview mirror + head-up display system + full LCD instrument + Internet of Vehicles system + in-vehicle occupant monitoring system", will all rely on SoC chips. On the other hand, MCU is suitable for engine control, power management (for example, battery management), wipers, windows, electric seats and other body controls. Multiple virtual machines can run on the SoC, such as the Linux system or QNX system as the underlying or integrated system, as well as the Android system (including native or quasi-native Android systems) or Android-like systems (for example, Hongmeng system, etc.), etc.

[0003] At present, the entire automotive system is no longer a single system, so the interactive communication between systems is particularly critical. However, the most direct way of interaction is that the MCU can only interact with LINUX / QNX, but cannot communicate directly with Android / Android-like systems. Similarly, Android / Android-like systems cannot communicate directly with MCUs, and both parties of the interaction between MCU and LINUX / QNX must have maintenance personnel to maintain the project. In actual projects, automotive industry developers often need to implement multi-chip interaction (referred to as "domain communication" in this article). Because there are communication requirements between each other, the interactive communication messages must be determined. If there is two-party communication, at least two developers need to add messages, and if there is three-party communication, at least three developers need to add messages. However, for the current multi-car manufacturers and multi-models, the functions provided cannot meet the development, debugging and problem analysis needs of developers (or support engineers). The reasons include: first, the communication between MCU and Android / Android-like system requires the participation of third-party LINUX / QNX, and the three parties cannot interact with each other arbitrarily; second, the program code is not platform-specific or portable, and any changes made by any of the three parties require re-intervention; third, the communication time is difficult to guarantee, and sometimes it will cause problems such as message loss; fourth, the manpower and time costs of later maintenance are high. Summary of the invention

[0004] The purpose of the present disclosure is to overcome the above-mentioned defects and provide a method for communication between processors of a vehicle, a system-level processor, a computing device or an in-vehicle system, a computer-readable storage medium, a computer program product and a vehicle.

[0005] The first aspect of the present disclosure proposes a method for communication between processors of a vehicle. The processor includes an interconnected microprocessor (MCU) and a system-level processor (SoC), and a first virtual machine and a second virtual machine are run on the SoC. The method is suitable for execution on the SoC, and includes: establishing corresponding communication connections with the first virtual machine, the second virtual machine, and the MCU respectively; sending a communication protocol file to the first virtual machine, the second virtual machine, and the MCU, wherein the communication protocol file indicates a message template to be followed in communication between the first virtual machine, the second virtual machine, and the MCU; receiving a communication message from at least one object in the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection; determining the target party of the communication message based on the communication protocol file; when the target party includes one or more objects in the first virtual machine, the second virtual machine, and the MCU, forwarding the communication message to the one or more objects via a corresponding communication connection established with the one or more objects.

[0006] The second aspect of the present disclosure proposes a system-on-chip (SoC) suitable for a vehicle. The SoC is interconnected to a microprocessor (MCU) of the vehicle, and a first virtual machine and a second virtual machine are run on the SoC, and a communication management process is performed on the SoC. The communication management process is configured to: establish corresponding communication connections with the first virtual machine, the second virtual machine, and the MCU respectively; send a communication protocol file to the first virtual machine, the second virtual machine, and the MCU, and the communication protocol file indicates the message template followed in the communication between the first virtual machine, the second virtual machine, and the MCU; receive a communication message from at least one object in the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection; determine the target party of the communication message based on the communication protocol file; when the target party includes one or more objects in the first virtual machine, the second virtual machine, and the MCU, forward the communication message to the one or more objects via the corresponding communication connection established with the one or more objects.

[0007] A third aspect of the present disclosure provides a computing device or an in-vehicle system, comprising a system-on-chip processor (SoC) according to the second aspect.

[0008] A fourth aspect of the present disclosure proposes a computing device or an in-vehicle system, comprising a microprocessor (MCU) and a system-on-chip (SoC) according to the second aspect, wherein the SoC is interconnected to the MCU.

[0009] A fifth aspect of the present disclosure proposes a vehicle, comprising: a system-on-chip processor (SoC) according to the second aspect or a computing device or an in-vehicle system according to the third or fourth aspect.

[0010] A sixth aspect of the present disclosure proposes a computer-readable storage medium having computer-executable instructions stored thereon, wherein the computer-executable instructions are used to execute the method for communication between processors of a vehicle according to the first aspect described above.

[0011] The seventh aspect of the present disclosure proposes a computer program product, which is tangibly stored on a computer-readable storage medium and includes computer-executable instructions, which, when executed, enable at least one processor to perform the method for communication between processors for a vehicle according to the first aspect described above.

[0012] The present disclosure utilizes the defined interactive communication protocol file to realize arbitrary direct interaction between multiple virtual machines and MCUs on the SoC (for example, the MCU can directly communicate with the Android / Android-like system), effectively ensuring the timeliness of mutual communication (i.e., faster response and faster startup) while avoiding excessive maintenance manpower and time costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The features, advantages and other aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings, in which several embodiments of the present disclosure are shown in an exemplary and non-limiting manner. In the accompanying drawings:

[0014] Figure 1 An exemplary vehicle is shown in which embodiments of the present disclosure may be applied.

[0015] Figure 2 A logical connection block diagram of a SoC and an MCU according to an embodiment of the present disclosure is shown.

[0016] Figure 3 A flow chart of a method for communication between processors of a vehicle according to an embodiment of the present disclosure is shown.

[0017] Figure 4 An exemplary visual editing table file for generating a communication protocol file according to an embodiment of the present disclosure is shown.

[0018] Figure 5 The interaction between an exemplary communication management process and the first and second virtual machines and the MCU according to an embodiment of the present disclosure is shown.

[0019] Figure 6 A first exemplary interaction sequence of an exemplary communication management process according to an embodiment of the present disclosure is shown.

[0020] Figure 7 A second exemplary interaction sequence of an exemplary communication management process according to an embodiment of the present disclosure is shown.

[0021] Figure 8 A third exemplary interaction sequence of an exemplary communication management process according to an embodiment of the present disclosure is shown.

[0022] Fig. 9 A block diagram of an exemplary computing device or in-vehicle system according to an embodiment of the present disclosure is shown.

[0023] Fig.10 A block diagram of another exemplary computing device or in-vehicle system according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0024] The various exemplary embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. Although the exemplary methods and devices described below include software and / or firmware executed on hardware among other components, it should be noted that these examples are merely illustrative and should not be regarded as restrictive. For example, it is considered that any or all hardware, software, and firmware components can be implemented exclusively in hardware, exclusively in software, or in any combination of hardware and software. Therefore, although exemplary methods and devices have been described below, it should be readily understood by those skilled in the art that the examples provided are not intended to limit the manner in which these methods and devices are implemented.

[0025] In addition, the flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions and operations of the methods and systems according to the various embodiments of the present disclosure. It should be noted that the functions marked in the boxes may also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession may actually be executed substantially in parallel, or they may sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the flowchart and / or block diagram, and the combination of boxes in the flowchart and / or block diagram, may be implemented using a dedicated hardware-based system that performs a specified function or operation, or may be implemented using a combination of dedicated hardware and computer instructions.

[0026] The terms "including", "comprising" and similar terms used herein are open terms, i.e., "including / including but not limited to", indicating that other contents may also be included. The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one other embodiment", etc.

[0027] The vehicle described in this specification may include motor vehicles, for example, cars, trucks, taxis, buses, shared cars and other means of transportation.

[0028] refer to Figure 1 , shows an exemplary vehicle 100 in which embodiments of the present disclosure may be applied. The vehicle 100 may include a system-on-chip (SoC) 110 and a microprocessor or microcontroller (MCU) 120. For example, the SoC 110 may include a CPU core module, a digital signal processor DSP module, a memory module, a communication interface module, etc., to implement various complex intelligent applications, such as an in-vehicle infotainment system, an in-vehicle autonomous driving system, etc. For example, the MCU 120 may be applicable to engine control, power management (e.g., battery management), body control such as wipers, windows, electric seats, etc. For example, the MCU 120 may be a traditional electronic control unit (ECU) or a part thereof. Figure 1As shown, SoC 110 and MCU 120 are communicatively connected to each other via a communication link 130 (e.g., a wired or wireless link). For example, each of SoC 110 and MCU 120 may include one or more of a UART interface, an SPI interface, an Ethernet interface, or other communication interfaces, and SoC 110 and MCU 120 may, for example, establish a UART communication connection via their respective UART interfaces, establish a SPI communication connection via their respective SPI interfaces, establish an Ethernet communication connection via their respective network interfaces, or establish other communication connections (e.g., a vehicle communication bus connection, a wireless communication connection, etc.) via their respective other communication interfaces. It should be understood that although Figure 1 Only one SoC and one MCU are interconnected, but the SoC can be interconnected with more MCUs (e.g., 2, 3, etc.), the MCU can be interconnected with more SoCs (e.g., 2, 3, etc.), and the technology of the present disclosure can be implemented on each SoC.

[0029] Multiple virtual machines can be run on the SoC, such as the Linux system or QNX system as the underlying or integrated system, and the Android system or Android-like system (for example, to realize the interaction between the vehicle and an external mobile terminal (for example, a mobile phone, a tablet computer, etc.)). Implementing the SoC+MCU architecture on the vehicle makes the vehicle system no longer single, and the interactive communication between systems is particularly critical. However, as mentioned above, the most direct interaction method available is that the MCU can only interact with LINUX / QNX, but cannot communicate directly with the Android / Android-like system, and the maintenance cost is high and it is difficult to ensure the timeliness of communication. For example, in the prior art, although the LINUX / QNX system and the Android system can communicate through shared memory, this method is difficult to ensure the timeliness of communication. How to realize multi-chip interaction in the vehicle (i.e., "domain communication") and ensure the timeliness of communication have become problems that must be solved in various scenarios, such as such scenarios protect but are not limited to the development, debugging, analysis, diagnosis, etc. of vehicle hardware / software by developers (or support engineers).

[0030] refer to Figure 2, shows an exemplary logical connection block diagram of the SoC and MCU according to an embodiment of the present disclosure. The SoC 110 and the MCU 120 each have a communication interface 111, 121, and are interconnected via a communication link 130. A first virtual machine 112 and a second virtual machine 113 are running on the SoC 110, and a communication management process 114 is also executed on the SoC 110. The communication management process 114 can be configured to establish a first communication connection 115 and a second communication connection 116 with the first virtual machine 112 and the second virtual machine 113, respectively, and to establish a third communication connection 117 with the MCU 120 (for example, via the communication interface 111 and the communication link 130). The communication management process 114 can implement direct communication interaction between each virtual machine on the SoC and the MCU and ensure the timeliness of communication, as described below. It should be understood that more virtual machines (for example, 3, 4, etc.) can be run on the SoC, and that the separate depiction of the virtual machine and the communication management process does not imply that they are independent of each other (that is, the two objects can be independent of each other, or one object can run on another object, etc.).

[0031] refer to Figure 3 , shows a flow chart of a method 300 for communication between processors of a vehicle according to an embodiment of the present disclosure. The method 300 may be applicable to Figure 1 of the vehicle 100 and may be provided by, for example Figure 1 and Figure 2 SoC 110, Figure 2 and Figure 5 Communication management process 114, Figure 7 A computing device or vehicle system 700 (including SoC 710), Figure 8 The method 300 includes steps 310-350.

[0032] In step 310, corresponding communication connections are established with the first virtual machine, the second virtual machine, and the MCU. For example, a first communication connection 115 and a second communication connection 116 are established with the first virtual machine 112 and the second virtual machine 113, respectively, and a third communication connection 117 is established with the MCU 120 (see Figure 2 ).

[0033] In step 320, a communication protocol file is sent to the first virtual machine, the second virtual machine, and the MCU, and the communication protocol file indicates the message template followed by the communication between the first virtual machine, the second virtual machine, and the MCU. For example, the SoC can receive the corresponding communication protocol file for each object in the first virtual machine, the second virtual machine, and the MCU from a device outside the SoC (e.g., a computer device, a server, etc.), and send the corresponding communication protocol file to each object. For example, the corresponding communication protocol file can be sent to each object in the format of a compiled code (e.g., a header file). For example, an Android or Android-like system can use a header file in Java format, a Linux system can use a header file in C++ format, an MCU can use a header file in C format, and so on. For example, the first virtual machine, the second virtual machine, and the MCU can read the corresponding communication protocol file at power-on startup, or can receive the corresponding communication protocol file after power-on startup. In this way, the communication protocol file can be updated as needed, and the updated communication protocol file can be provided to the first virtual machine, the second virtual machine, and the MCU, so that when the object or its number changes (e.g., when a new virtual machine or MCU joins or replaces an old virtual machine or MCU), communication between multiple objects can be realized based on the updated communication protocol file.

[0034] In step 330, a communication message is received from at least one of the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection. For example, the communication message may be monitored and received via the first communication connection 115, the second communication connection 116, and the third communication connection 117 between the first virtual machine 112, the second virtual machine 113, and the MCU 120, respectively.

[0035] In step 340, the target party of the communication message is determined based on the communication protocol file. For example, the communication message received on the corresponding communication connection can be parsed based on the corresponding communication protocol to determine the target recipient of the communication message.

[0036] In step 350, when the target party includes one or more objects in the first virtual machine, the second virtual machine, and the MCU, the communication message is forwarded to the one or more objects via the corresponding communication connection established with the one or more objects. For example, the received communication message can be forwarded to the target recipient in the first virtual machine 112, the second virtual machine 113, and the MCU 120 via the first communication connection 115, the second communication connection 116, and the third communication connection 117 between the first virtual machine 112, the second virtual machine 113, and the MCU 120.

[0037] Compared with the existing technology, Figure 3Method 300 can achieve unified communication standards (for example, including communication time, communication bandwidth, etc.) to realize direct interaction between multiple virtual machines on MCU and SoC by formulating a communication protocol for interaction for domain communication. The program code is platform-specific or portable. If any party among the multiple parties makes a change, there is no need to re-intervene (only the communication protocol needs to be updated). The communication time can be guaranteed and problems such as message loss can be avoided, while avoiding excessive post-maintenance manpower and time costs.

[0038] In some embodiments, the first virtual machine may be a Linux system or a QNX system, and establishing a corresponding communication connection with the first virtual machine may include establishing an inter-process communication (IPC) connection with the first virtual machine. For example, the communication management process 114 may be executed on the first virtual machine 112 (domain) and establish an inter-process communication connection with an application on the first virtual machine 112 (domain).

[0039] In some embodiments, the second virtual machine may be an Android system or an Android-like system, and establishing a corresponding communication connection with the second virtual machine may include establishing a Socket communication connection with the second virtual machine. For example, the communication management process 114 may establish a Socket communication connection with the second virtual machine 113. Since the first virtual machine 112 (e.g., a Linux system or a QNX system) has a shorter startup time than the second virtual machine 113 (e.g., an Android system or an Android-like system), the SocketServer end may be set on the communication management process 114 side and the SocketClient end may be set on the second virtual machine 113, so that after the first virtual machine 112 is started, the SocketServer may listen to a certain port on the server side to wait for the SocketClient of the second virtual machine 113 to connect to the Socket on the corresponding port (see Figure 5 ).

[0040] In some embodiments, the second virtual machine may run on the first virtual machine, or the first virtual machine and the second virtual machine may run on a virtual machine manager running on the SoC. In some examples, a second virtual machine 113 such as an Android system or an Android-like system may run on a first virtual machine 112 such as Linux or QNX. In other examples, a second virtual machine 113 such as an Android system or an Android-like system and a first virtual machine 112 such as Linux or QNX may run on a virtual machine manager (e.g., QNX Hypervisor, etc.) running on the SoC 110. In other examples, a second virtual machine 113 such as an Android system or an Android-like system and a first virtual machine 112 such as Linux or QNX may run on the SoC 110 using any known or future developed standards and / or architectures.

[0041] In some embodiments, establishing a corresponding communication connection with the MCU may include establishing at least one of a UART communication connection, an SPI communication connection, or an Ethernet communication connection with the MCU. For example, the communication management process 114 may establish a UART communication connection, an SPI communication connection, an Ethernet communication connection, or other communication connections (e.g., a vehicle communication bus connection, a wireless communication connection, etc.) with the MCU 120. In some examples, the MCU 120 may not support an Ethernet communication mode, and the communication management process 114 may communicate with the MCU 120 via UART or SPI.

[0042] In some embodiments, the message template indicated by the communication protocol file may include the following parameters: sender, receiver, name, format, and definition of the message.

[0043] In some embodiments, receiving a communication message from at least one object in the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection may include: receiving a communication message filled with a message template from at least one object in the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection.

[0044] In some embodiments, determining a target party of a communication message based on a communication protocol file may include: parsing a recipient of the communication message based on a message template.

[0045] In some embodiments, the communication protocol file may be generated based on a visual editing table file, and the visual editing table file may include visual editing table items corresponding to the parameters included in the message template.

[0046] In some embodiments, the visual editing table file may be converted into corresponding communication protocol files that conform to corresponding header file formats of the first virtual machine, the second virtual machine, and the MCU, respectively.

[0047] refer to Figure 4 , shows an exemplary visual editing table file for generating a communication protocol file according to an embodiment of the present disclosure. Figure 4As shown, the visual editing table file may include multiple rows and columns. The first row represents the parameters included in the message template, for example, the sender 401, the receiver 402, the message name 403, the data format 404, and the data definition 405 of the message, or may also include other customizable parameters. For example, the message type can be used instead of the message name. The remaining rows represent template instances of the message template, for example, including visual editing table items corresponding to the parameters included in the message template. For example, the visual editing table file includes the following rows: the second row represents a template instance of a communication message sent from the MCU to the Android system, which is used to request the status of the Android system; the third row represents a template instance of a communication message sent from the Android system to the MCU and the QNX system, which is used to respond to the request and reply to the status of the Android system; the fourth row represents a template instance of a communication message sent from the MCU to the QNX system, which is used to request the status of the QNX system; the fifth row represents a template instance of a communication message sent from the QNX system to the MCU and the Android system, which is used to respond to the request and reply to the status of the QNX system. It should be understood that Figure 4 The visual editing table file is used for illustration only and is not limiting. The template instance in the message template can represent a communication message sent from one object to one or more objects, or a communication message sent from one or more objects to one object, or a communication message sent from multiple objects to multiple objects.

[0048] For example, the visual editing table file may be a table file in an Excel format, so that the visual editability of the message template can be easily realized, so as to update the message template, such as adding or reducing parameters included in the message template, adding or reducing message instances of the message template, etc. The Excel file can be converted into a header file of multiple domains (e.g., MCU, Linux or QNX system, Android or Android-like system) via a script program (e.g., Python, etc.), so as to save the maintenance cost of multiple people.

[0049] When the second virtual machine 113 such as an Android system or an Android-like system, the first virtual machine 112 such as Linux or QNX, and the MCU 130 communicate with each other, each object can use the message template indicated by the corresponding communication protocol file to fill in and generate a communication message, and send the generated communication message to the communication management process 114. The communication management process 114 can parse the recipient of the communication message based on the message template, and convey the communication message to the recipient via the communication connection with the recipient. Figure 5-Figure 8 To describe the modules of an exemplary communication management process and exemplary interactions with the first and second virtual machines and the MCU.

[0050] refer to Figure 5 , shows the interaction between the exemplary communication management process according to an embodiment of the present disclosure and the first and second virtual machines and the MCU. Figure 5 As shown, the communication management process 114 runs on the first virtual machine 112 and includes a startup module 1141, an identification module 1142 and a channel transceiver module 1143. The startup module 1141 is responsible for the process startup of the entire communication management process 114. The identification module 1142 is used to identify from which domain (object) the communication message is forwarded to another domain (object). The channel transceiver module 1143 is responsible for receiving and sending dedicated channels (for example, UART / SPI in the direction of MCU, Socket channel in the direction of Android system). These modules of the communication management process 114 can interact (as indicated by the dotted arrows) through the internal communication of the SoC (for example, inter-process communication). Similarly, the identification module 1142 can interact with other applications 1121 on the first virtual machine 112 through the internal communication of the SoC (for example, inter-process communication) (as indicated by the dotted arrows).

[0051] The channel transceiver module 1143 includes a Socket communication submodule 1144, a UART communication submodule 1145, and an SPI communication submodule 1146. The Socket communication submodule 1144 is responsible for handshake communication, receiving and sending messages with the second virtual machine 113 such as an Android or Android-like system (for example, the Socket communication module 1131 thereon), the UART communication submodule 1145 is responsible for the file block operation of the UART interface, and the SPI communication submodule 1146 is responsible for the file block operation of the SPI interface.

[0052] refer to Figure 6 , shows a first exemplary interaction sequence 400 of an exemplary communication management process according to an embodiment of the present disclosure. Figure 6 As shown, the identification module 1142 schedules the Socket communication submodule 1144 of the channel transceiver module 1143, wherein the Socket communication submodule 1144 is divided into two threads NetRx (1144a) and NetTx (1144b). For example, the threads NetRx and NetTx can be scheduled periodically. If the identification module 1142 distributes the Socket message to the thread NetTx (410), the thread NetTx immediately pushes the message to the network (NetPort) (420). If the thread NetRx obtains the message from the network (NetPort) (430), the thread NetRx forwards the message to the identification module 1142 (for identifying which domain the message is forwarded from to another domain) (440).

[0053] refer to Figure 7 , shows a second exemplary interaction sequence 500 of an exemplary communication management process according to an embodiment of the present disclosure. Figure 7As shown, the identification module 1142 schedules the UART communication submodule 1145 of the channel transceiver module 1143, wherein the UART communication submodule 1145 is divided into two threads UartRx (1145a) and UartTx (1145b). For example, the threads UartRx and UartTx can be scheduled periodically. If the identification module 1142 distributes the UART message to the thread UartTx (510), the thread UartTx immediately writes the message to the uart file block (520). If the thread UartRx obtains the message from the uart file block (530), the thread UartRx forwards the message to the identification module 1142 (for identifying which domain the message is forwarded from to another domain) (540).

[0054] refer to Figure 8 , shows a third exemplary interaction sequence 600 of an exemplary communication management process according to an embodiment of the present disclosure. Figure 8 As shown, the identification module 1142 schedules the SPI communication submodule 1146 of the channel transceiver module 1143, wherein the SPI communication submodule 1146 is divided into two threads SpiRx (1146a) and SpiTx (1146b). For example, threads SpiRx and SpiTx can be scheduled periodically. If the identification module 1142 distributes the SPI message to the thread SpiTx (610), the thread SpiTx writes the message to the spi file block (620). If the thread SpiRx obtains the message from the spi file block (630), the thread SpiRx forwards the message to the identification module 1142 (for identifying which domain the message is forwarded from to another domain) (640).

[0055] refer to Fig. 9 , a block diagram of an exemplary computing device or vehicle-mounted system 700 according to an embodiment of the present disclosure is shown. The computing device or vehicle-mounted system 700 includes a microprocessor (MCU) 720 and a system-level processor (SoC) 710 interconnected with the MCU 720 (e.g., via a communication link 730). For example, the SoC 710 may be Figure 1 and Figure 2 The SoC 110 and the MCU 120 may be Figure 1 , Figure 2 and Figure 5 MCU 120. For example, the computing device or vehicle system 700 may be an intelligent cockpit system, an intelligent navigation system, etc. Any one or more steps of the methods described in the above embodiments may be implemented on the SoC 710 to implement direct interaction between different domains (e.g., interaction between the MCU and multiple virtual machines running on the SoC).

[0056] refer to Fig.10, a block diagram of another exemplary computing device or vehicle-mounted system 800 according to an embodiment of the present disclosure is shown. The computing device or vehicle-mounted system 800 includes a system-level processor (SoC) 810, which is interconnected to a microprocessor (not shown). For example, the computing device or vehicle-mounted system 800 can be an intelligent cockpit system, an intelligent navigation system, etc. Any one or more steps of the methods described in the above embodiments can be implemented on the SoC 810 to achieve direct interaction between different domains (for example, interaction between an MCU and multiple virtual machines running on the SoC).

[0057] As before combined Figure 1-Figure 8 As described, the present disclosure provides a system-on-chip (SoC) suitable for a vehicle, wherein the SoC is interconnected to a microprocessor (MCU) of the vehicle, and a first virtual machine and a second virtual machine are run on the SoC, and a communication management process is executed on the SoC, wherein the communication management process is configured to execute any one or more steps of the methods described in the above embodiments to achieve direct interaction between different domains (for example, interaction between the MCU and multiple virtual machines running on the SoC).

[0058] The present disclosure further provides a vehicle, which may include, for example Figure 1 and Figure 2 and a system-on-chip processor (SoC) 110, Fig. 9 , Fig.10 Any one of the computing devices or vehicle-mounted systems 700, 800 to implement any one or more steps of the method in the above embodiments.

[0059] In addition, alternatively, the above method can be implemented by a computer-readable storage medium. Computer-readable storage media are loaded with computer-readable program instructions for executing various embodiments of the present disclosure. Computer-readable storage media can be a tangible device that can hold and store instructions used by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), portable compact disk read-only memories (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or protruding structures in grooves on which instructions are stored, and any suitable combination of the above. The computer-readable storage medium used herein is not to be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or an electrical signal transmitted through wires.

[0060] Therefore, in another embodiment, the present disclosure provides a computer-readable storage medium having computer-executable instructions stored thereon, where the computer-executable instructions are used to execute the methods in various embodiments of the present disclosure.

[0061] In another embodiment, the present disclosure proposes a computer program product, which is tangibly stored on a computer-readable storage medium and includes computer-executable instructions that, when executed, cause at least one processor to perform the methods in various embodiments of the present disclosure.

[0062] In general, various example embodiments of the present disclosure may be implemented in hardware or dedicated circuits, software, firmware, logic, or any combination thereof. Certain aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device. When various aspects of the embodiments of the present disclosure are illustrated or described as block diagrams, flow charts, or using some other graphical representation, it will be understood that the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof as non-limiting examples.

[0063] As discussed above, although the present application discusses applications in scenarios such as development, debugging, analysis, and diagnosis of vehicle hardware / software by developers (or support engineers), the method for communication between processors of a vehicle, computing device or on-board system, non-temporary computer-readable medium, and computer program product disclosed herein are also applicable to other arrangements requiring communication between different domains.

[0064] Computer-readable program instructions or computer program products for executing the various embodiments of the present disclosure can also be stored in the cloud. When needed, users can access the computer-readable program instructions for executing an embodiment of the present disclosure stored in the cloud through mobile Internet, fixed network or other networks, thereby implementing the technical solutions disclosed in accordance with the various embodiments of the present disclosure.

[0065] Although the embodiments of the present disclosure have been described with reference to several specific embodiments, it should be understood that the embodiments of the present disclosure are not limited to the specific embodiments disclosed. The embodiments of the present disclosure are intended to cover various modifications and equivalent arrangements included in the spirit and scope of the appended claims. The scope of the claims is consistent with the broadest interpretation, thereby including all such modifications and equivalent structures and functions.

Claims

1. A method for communication between processors of a vehicle, the processors comprising an interconnected microprocessor (MCU) and a system-on-chip (SoC), a first virtual machine and a second virtual machine running on the SoC, the method being suitable for execution on the SoC, and comprising: Establish corresponding communication connections with the first virtual machine, the second virtual machine, and the MCU respectively; Sending a communication protocol file to the first virtual machine, the second virtual machine, and the MCU, where the communication protocol file indicates a message template followed in communication between the first virtual machine, the second virtual machine, and the MCU; receiving a communication message from at least one object in the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection; Determining a target party of the communication message based on the communication protocol file; When the target party includes the first virtual machine, the second virtual machine, and one or more objects in the MCU, the communication message is forwarded to the one or more objects via corresponding communication connections established with the one or more objects.

2. The method according to claim 1, wherein: The first virtual machine is a Linux system or a QNX system; and Establishing a corresponding communication connection with the first virtual machine includes establishing an inter-process communication connection with the first virtual machine.

3. The method according to claim 1 or 2, wherein: The method is suitable for execution on the first virtual machine, and The second virtual machine is an Android system or an Android-like system; Establishing a corresponding communication connection with the second virtual machine includes establishing a Socket communication connection with the second virtual machine.

4. The method according to claim 3, wherein: The second virtual machine runs on the first virtual machine; or The first virtual machine and the second virtual machine run on a virtual machine manager running on the SoC.

5. The method according to claim 1, wherein: Establishing a corresponding communication connection with the MCU includes establishing at least one of a UART communication connection, a SPI communication connection, or an Ethernet communication connection with the MCU.

6. The method according to claim 1, wherein: The message template includes the following parameters: sender, receiver, name, format, and definition of the message.

7. The method according to claim 1, wherein: Receiving a communication message from at least one object in the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection includes: A communication message filled with the message template is received from at least one object among the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection.

8. The method according to claim 6 or 7, wherein: Determining a target party of the communication message based on the communication protocol file includes: Based on the message template, a recipient of the communication message is parsed.

9. The method according to claim 1, wherein: The communication protocol file is generated based on a visual editing table file, and the visual editing table file includes visual editing table items corresponding to the parameters included in the message template.

10. The method according to claim 1, further comprising: The visual editing table file is converted into corresponding communication protocol files that conform to the corresponding header file formats of the first virtual machine, the second virtual machine, and the MCU respectively.

11. A system-on-chip (SoC) adapted for use in a vehicle, wherein the SoC is interconnected to a microprocessor (MCU) of the vehicle, and a first virtual machine and a second virtual machine are run on the SoC, and a communication management process is executed on the SoC, wherein the communication management process is configured to: Establish corresponding communication connections with the first virtual machine, the second virtual machine, and the MCU respectively; Sending a communication protocol file to the first virtual machine, the second virtual machine, and the MCU, where the communication protocol file indicates a message template followed in communication between the first virtual machine, the second virtual machine, and the MCU; receiving a communication message from at least one object in the first virtual machine, the second virtual machine, and the MCU via a corresponding communication connection; Determining a target party of the communication message based on the communication protocol file; When the target party includes the first virtual machine, the second virtual machine, and one or more objects in the MCU, the communication message is forwarded to the one or more objects via corresponding communication connections established with the one or more objects.

12. A computing device or an in-vehicle system comprising the system-on-chip processor (SoC) according to claim 11.

13. A computing device or an in-vehicle system comprising: Microprocessor (MCU); as well as The system-on-chip (SoC) of claim 11, interconnected to the MCU.

14. A vehicle comprising the system-on-chip (SoC) according to claim 11 or the computing device or the in-vehicle system according to claim 12 or 13. 15 . A computer-readable storage medium having computer-executable instructions stored thereon, the computer-executable instructions being used to execute the method for communication between processors of a vehicle according to any one of claims 1 to 10. 16 . A computer program product tangibly stored on a computer-readable storage medium and comprising computer-executable instructions which, when executed, cause at least one processor to perform the method for inter-processor communication for a vehicle according to any one of claims 1 to 10.

Images