Vehicle communication method and device, vehicle, storage medium and program product

Abstract

The invention relates to the technical field of intelligent cabins, and discloses a vehicle communication method and device, a vehicle, a storage medium and a program product.The intelligent cabin is divided into an instrument system, a remote communication system and a software application system which are independent, isolation of hardware resources is achieved, independent physical channels are distributed for all the systems, and the communication efficiency is improved. And the isolation and safety of the system are improved. And the instrument system decrypts the first encrypted data sent by the main controller to obtain remote communication data and / or software application data of other systems, so that information transmission between hardware isolation systems is realized, and system data leakage caused by memory sharing can be avoided. And the private communication protocol between the instrument system and the software application system is designed, and the first original data obtained through decryption is sent to the software application system, so that the communication delay between the systems is reduced, and the real-time performance of data display and instruction execution of the instrument system is improved.

Description

Technical Field

[0001] This invention relates to the field of smart cockpit technology, specifically to vehicle communication methods, devices, vehicles, storage media, and software products. Background Technology

[0002] With the development of automotive technology, automotive hardware platforms and intelligent driving systems are constantly being upgraded. In traditional solutions, the instrument system and telematics box (TBOX) are often located in a single partition, using a single physical resource sharing method.

[0003] Traditional solutions lack effective isolation mechanisms between different systems. Once one system is attacked, attackers can steal data from other systems through methods such as shared memory, severely impacting system security. Furthermore, communication between multiple systems typically relies on standardized protocols, such as CAN and LIN. While these protocols are designed with system compatibility and universality in mind, in practice, the presence of protocol conversion layers can significantly increase communication latency between systems, affecting real-time performance. Summary of the Invention

[0004] This invention provides a vehicle communication method, device, vehicle, storage medium, and program product to solve the problems of low security and low real-time performance of existing hardware resource sharing schemes.

[0005] In a first aspect, the present invention provides a vehicle communication method, wherein the vehicle includes a main controller and a smart cockpit, the smart cockpit being divided into a hardware-isolated instrument system, a remote communication system, and a software application system; the method is applied to the instrument system, and the method includes: Receive the first encrypted data sent by the main controller through the first physical channel; The first encrypted data is decrypted to obtain the first original data; wherein the first original data includes remote communication data and / or software application data, the remote communication data includes data sent by the remote communication system to the main controller through the second physical channel, and the software application data includes data sent by the software application system to the main controller through the third physical channel; Based on a preset private protocol, the first raw data is encapsulated into a first private data packet and sent to the software application system; wherein, the preset private protocol is a private network communication protocol between the instrument system and the software application system.

[0006] This invention achieves hardware resource isolation by dividing the intelligent cockpit into independent instrument systems, remote communication systems, and software application systems, and allocates independent physical channels to each system, thereby improving system isolation and security. The instrument system decrypts the first encrypted data sent by the main controller to obtain remote communication data and / or software application data from other systems, enabling information transmission between hardware-isolated systems and avoiding system data leakage caused by shared memory. Furthermore, by designing a private communication protocol between the instrument system and the software application system, the decrypted first raw data is sent to the software application system, reducing inter-system communication latency and improving the real-time performance of instrument system data display and command execution.

[0007] In some alternative implementations, the method further includes: Receive the second private data packet sent by the software application system; The second private data packet is parsed based on a preset private protocol to obtain the second raw data. The second original data is encrypted into second encrypted data, and the second encrypted data is sent to the main controller through the first physical channel.

[0008] This invention addresses hardware-isolated instrument systems and software application systems. The instrument system communicates with the software application system via a proprietary protocol, parsing and encrypting data packets sent by the software application system. This data is then forwarded from the software application system to the main controller via a first physical channel between the instrument system and the main controller, achieving secure encrypted data transmission and communication between different systems. Furthermore, the proprietary protocol design significantly reduces communication latency between systems.

[0009] In some alternative implementations, before receiving the first encrypted data sent by the master controller via the first physical channel, the method further includes: Send a handshake connection request to the main controller; the handshake connection request includes a random number; Receive the random number encrypted data packet returned by the main controller based on the handshake connection request. If the random number encrypted data packet is successfully verified, send encrypted response data to the main controller. Receive initial status data returned by the main controller based on encrypted response data. If the initial status data is found to be valid, establish a handshake connection with the main controller.

[0010] This invention initiates authentication by sending a handshake request containing a random number to the main controller. It then uses the random number returned by the main controller to encrypt data packets, completing the initial verification of the main controller's identity. Upon successful verification, it continues to send encrypted response data. Finally, by validating the initial state data returned by the main controller, it completes bidirectional authentication and state synchronization between the instrument system and the main controller. This achieves identity authentication and dynamic key negotiation between the communicating parties, thereby establishing a secure handshake connection and improving the reliability and integrity of the connection establishment process.

[0011] In some alternative implementations, after receiving the handshake identifier encrypted data packet returned by the master controller based on the handshake connection request, the method further includes: The stored random number is encrypted to obtain the first encrypted random number; The encrypted random number data packet sent by the main controller is decrypted to obtain the second encrypted random number; If the first encrypted random number and the second encrypted random number are found to be the same, the random number encrypted data packet is deemed to have passed verification.

[0012] The instrument system of the present invention encrypts the original random number stored in itself to generate a first encrypted random number. At the same time, it decrypts the received encrypted random number data packet sent by the main controller to obtain the first encrypted random number. By comparing whether the two are consistent, it can effectively verify whether the main controller holds the correct encryption key, thereby ensuring that the instrument system and the main controller at both ends of the communication link are legitimate authorized devices, improving the reliability of the identity authentication process and the system security.

[0013] In some alternative implementations, after establishing a handshake connection with the main controller, the method further includes: Determine the time difference between the current timestamp and the synchronization timestamp; where the synchronization timestamp is used to characterize the last communication time between the instrumentation system and the main controller; If the detected time difference exceeds the preset time difference, record one heartbeat failure and determine whether the number of heartbeat failures has reached the preset number; If the number of failed heartbeats reaches the preset number, re-establish the handshake connection with the main controller and reset the number of failed heartbeats.

[0014] This invention continuously compares the time difference between the current timestamp and the last communication timestamp to detect abnormal interruptions in the communication link in real time. Upon detecting a timeout, it uses a cumulative count of failed heartbeats to avoid misjudgments and frequent reconnections caused by momentary network fluctuations. Finally, after confirming the connection failure, it triggers a handshake reconnection to restore communication between the two ends. This improves the reliability of the instrument system in the face of interference or faults, ensuring the continuity and stability of vehicle communication.

[0015] In some alternative implementations, after decrypting the first encrypted data to obtain the first original data, the method further includes: Determine the data access permissions for the software application system; Based on data access permissions, the first original data is verified for permissions. If the permission verification of the first original data is passed, the first original data is encapsulated into a first private data packet based on a preset private protocol and sent to the software application system.

[0016] This invention determines the data access permissions of software application systems to instrument systems through application-layer permission management and data access whitelisting mechanisms, strictly restricts user applications' access permissions to sensitive vehicle data, and builds a security barrier adapted to the characteristics of heterogeneous systems while ensuring efficient communication.

[0017] In some alternative implementations, encrypting the second original data into second encrypted data includes: Construct the first state matrix based on the second original data; Construct a first key matrix, and generate multiple first-round keys based on the first key matrix; Based on multiple first-round keys, multiple rounds of encryption operations are performed on the first state matrix to obtain the second encrypted data.

[0018] This invention generates round keys for multiple rounds of encryption based on the expansion of the first key matrix, and performs multiple rounds of encryption on the second original data sent by the software application system to ensure the strength and reliability of the encryption operation. This enables end-to-end encrypted transmission of application layer data from the instrument system to the main controller, preventing data from being stolen or tampered with during transmission and ensuring the security and integrity of user commands and status information.

[0019] In some optional implementations, the first encrypted data is decrypted to obtain the first original data, including: Construct a second state matrix based on the first encrypted data; Construct a second key matrix, and generate multiple second-round keys based on the second key matrix; Based on multiple second-round keys, multiple rounds of decryption operations are performed on the second state matrix to obtain the first original data; wherein, the decryption operation is the inverse process of the encryption operation.

[0020] This invention generates a second-round key for multi-round decryption based on the expansion of the second key matrix. It reconstructs the received second encrypted data into the first original data, ensuring that the encrypted data can be uniquely and correctly restored to the original instruction or status information. This ensures the reliable decryption and use of the data at the receiving end, thereby forming a data security transmission system in conjunction with the encryption process. It prevents the loss of legitimate information due to the inability to decrypt, and ensures the integrity and continuity of the intelligent cockpit system's functions.

[0021] Secondly, the present invention provides a vehicle communication device, wherein the vehicle includes a main controller and a smart cockpit, the smart cockpit being divided into a hardware-isolated instrument system, a remote communication system, and a software application system; the device is applied to the instrument system, and the device includes: The first processing module is used to receive the first encrypted data sent by the main controller through the first physical channel; The second processing module is used to decrypt the first encrypted data to obtain the first original data; wherein the first original data includes remote communication data and / or software application data, the remote communication data includes data sent by the remote communication system to the main controller through the second physical channel, and the software application data includes data sent by the software application system to the main controller through the third physical channel; The third processing module is used to encapsulate the first raw data into a first private data packet and send it to the software application system based on a preset private protocol; wherein, the preset private protocol is a private network communication protocol between the instrument system and the software application system.

[0022] Thirdly, the present invention provides a vehicle, which includes a main controller and an intelligent cockpit, wherein the intelligent cockpit is divided into a hardware-isolated instrument system, a remote communication system and a software application system; The instrument system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes the computer instructions to perform the vehicle communication method of the first aspect or any corresponding embodiment described above.

[0023] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the vehicle communication method of the first aspect or any corresponding embodiment thereof.

[0024] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the vehicle communication method of the first aspect or any corresponding embodiment thereof.

[0025] The beneficial effects of this invention are as follows: This invention achieves hardware resource isolation by dividing the intelligent cockpit into independent instrument systems, remote communication systems, and software application systems, and allocates independent physical channels to each system, thereby improving system isolation and security. The instrument system decrypts the first encrypted data sent by the main controller to obtain remote communication data and / or software application data from other systems, enabling information transmission between hardware-isolated systems and avoiding system data leakage caused by shared memory. Furthermore, by designing a private communication protocol between the instrument system and the software application system, the decrypted first raw data is sent to the software application system, reducing inter-system communication latency and improving the real-time performance of instrument system data display and command execution. Attached Figure Description

[0026] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of the present invention; Figure 2 This is a structural block diagram of a conventional solution according to an embodiment of the present invention; Figure 3 This is a structural block diagram of a vehicle according to an embodiment of the present invention; Figure 4 This is a schematic flowchart of a first embodiment of a vehicle communication method according to the present invention; Figure 5 This is a second flowchart illustrating a vehicle communication method according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the handshake connection initiation process according to an embodiment of the present invention; Figure 7 This is a flowchart illustrating the handshake process according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the heartbeat monitoring process according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the data transmission process of a software application system according to an embodiment of the present invention; Figure 10 This is a schematic diagram of a private data packet according to an embodiment of the present invention; Figure 11 This is a flowchart illustrating the encryption operation according to an embodiment of the present invention; Figure 12This is a flowchart illustrating the decryption operation according to an embodiment of the present invention; Figure 13 This is a schematic diagram of the data transmission process of an instrument system according to an embodiment of the present invention; Figure 14 This is a structural block diagram of a vehicle communication device according to an embodiment of the present invention; Figure 15 This is a schematic diagram of the hardware structure of the instrument system according to an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0030] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0031] As an optional application scenario of this invention, such as Figure 1 As shown, the vehicle communication system may include at least one terminal device and at least one server. Figure 1 The system is illustrated in the example, which includes a computer 101, a mobile terminal 102, and a server 103, and the terminal devices such as the computer 101 and the mobile terminal 102 are connected to the server 103 through a network 110.

[0032] Specifically, the terminal device can be a smartphone, tablet, laptop, PDA, desktop computer, game console, smart TV, smart wearable device, in-vehicle terminal, VR (Virtual Reality) device, AR (Augmented Reality) device, etc. Server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranet, local area network, wide area network, mobile communication network, and combinations thereof.

[0033] With the development of automotive technology, more and more cars are undergoing hardware platform upgrades and intelligent driving upgrades. Automotive chips have iterated from the older MTK8665 board to the newer MTK8675 and MTK8676, and have now been updated to the MTK8678 platform. Traditional solutions typically adopt a single physical resource sharing approach when designing in-vehicle systems, lacking effective isolation mechanisms between different systems.

[0034] Traditional solutions share the same chip board across different systems, such as Figure 2 As shown, the instrument system and TBOX are located in the same partition, establishing a data communication link with the underlying system through a Serial Peripheral Interface (SPI). The instrument system and software application systems (such as Android systems) communicate and transmit data based on the Transmission Control Protocol (TCP). Once one system is attacked, the attacker can steal data from other systems through methods such as shared memory. For example, an attacker can obtain instrument data through the TBOX, seriously affecting the system's security.

[0035] In addition, communication between multiple systems usually relies on standardized protocols, such as CAN and LIN protocols. These protocols are designed with compatibility and universality in mind, but in practical applications, the existence of protocol conversion layers leads to a significant increase in communication latency, affecting the real-time performance of the system.

[0036] This invention provides a vehicle communication method that divides the smart cockpit into independent instrument systems, remote communication systems, and software application systems, achieving hardware resource isolation and allocating independent physical channels to each system, thereby improving system isolation and security. The instrument system decrypts the first encrypted data sent by the main controller to obtain remote communication data and / or software application data from other systems, enabling information transmission between hardware-isolated systems and avoiding system data leakage caused by shared memory. Furthermore, by designing a private communication protocol between the instrument system and the software application system, communication latency between systems is reduced, improving the real-time performance of instrument system data display and command execution.

[0037] According to embodiments of the present invention, a vehicle is provided, such as Figure 3 As shown, the vehicle includes a main control system and a smart cockpit. An isolated architecture is constructed using Hypervisor virtualization technology, dividing the entire smart cockpit into a hardware-isolated instrument system, a remote communication system, and a software application system. The main control system includes a main controller (MCU), the remote communication system includes a TBOX, and the software application system can be an Android system. This hardware-level virtualization boundary achieves physical isolation between core functions and extended functions, ensuring the secure isolation of remote communication data, instrument data, and software application data.

[0038] Specifically, at the communication architecture level, the main controller and the instrumentation system are connected through the first physical channel SPI1, the main controller and the remote communication system are connected through the second physical channel SPI2, and the main controller and the software application system are connected through the third physical channel SPI3.

[0039] Specifically, the instrument system receives the first encrypted data sent by the master controller via the first physical channel SPI1. Next, the instrument system decrypts the first encrypted data to obtain the first raw data; wherein the first raw data includes remote communication data and / or software application data, the remote communication data including data sent by the remote communication system to the master controller via the second physical channel SPI2, and the software application data including data sent by the software application system to the master controller via the third physical channel SPI3. Then, based on a preset private protocol, the instrument system encapsulates the first raw data into a first private data packet and sends it to the software application system; wherein the preset private protocol is a private network communication protocol between the instrument system and the software application system.

[0040] See you again Figure 3The main controller (MCU) acts as the core hub, managing the encrypted transmission of remote communication data, instrument data, and software application data (such as vehicle information data) through three independent SPI channels. For example, the first physical channel, SPI1, is responsible for high-speed synchronization of instrument parameters such as vehicle status; the second physical channel, SPI2, is dedicated to the encrypted transmission of vehicle-to-cloud interaction data for the 4G / 5G module; and the third physical channel, SPI3, independently carries the verification transmission of OTA upgrade packages for the application system. The isolation of physical channels avoids data conflicts.

[0041] Specifically, see again Figure 3 The instrument system internally uses a proprietary protocol processing module for data routing, while the instrument middleware provides a unified communication interface externally. The Human-Machine Interface (HMI) module handles visualization rendering. The communication link between the instrument system and the main controller employs AES-128 algorithm for end-to-end encryption. A dynamic key negotiation mechanism is introduced during the handshake phase, along with a timeout reconnection mechanism and periodic heartbeat monitoring to ensure connection stability. Furthermore, it provides real-time interception of risks such as communication anomalies and data tampering.

[0042] See you again Figure 3 The hardware layer (Vehicle module) on the software application system (such as the Android system) can establish a long TCP connection with the instrument system's private protocol processing module through the communication base library (event-driven abstract interface library) to achieve efficient interaction between vehicle data and the APP application layer. TBOX extends the communication link to cloud control through the vehicle cloud platform.

[0043] Compared to the traditional scheme where instruments and TBOX are partitioned together, this embodiment uses Hypervisor technology to achieve independent partitioning of the instrument system, remote communication system, and software application system, improving system isolation and security. Through modular design such as SPI channel division of labor, private protocol encapsulation, and middleware interface abstraction, communication links are decoupled. Combined with encryption, heartbeat monitoring, and layered verification mechanisms, the real-time performance of the instrument system and the scalability of the software application ecosystem are ensured while comprehensively improving the security and robustness of cross-system communication.

[0044] According to an embodiment of the present invention, a vehicle communication method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0045] This embodiment provides a vehicle communication method, which can be used for, for example Figure 2 The instrument system shown, such as the instrument display, etc. Figure 4 This is a flowchart of a vehicle communication method according to an embodiment of the present invention, such as... Figure 4 As shown, the process includes the following steps: Step S401: Receive the first encrypted data sent by the main controller through the first physical channel.

[0046] Specifically, the main controller and the instrumentation system are connected via the first physical channel SPI1. The main controller encrypts the first raw data to be transmitted and sends the encrypted data to the instrumentation system via the first physical channel SPI1.

[0047] Step S402: Decrypt the first encrypted data to obtain the first original data; wherein, the first original data includes remote communication data and / or software application data, the remote communication data includes data sent by the remote communication system to the main controller through the second physical channel, and the software application data includes data sent by the software application system to the main controller through the third physical channel.

[0048] Specifically, after receiving the first encrypted data sent by the main controller, the instrument system decrypts it. With the instrument system, software application system and remote communication system hardware isolated, the remote communication data of the remote communication system and the software application data of the software application system are obtained, realizing data communication and transmission between multiple systems, thereby preventing attackers from directly obtaining the underlying data of the instrument system or software application system through the remote communication system.

[0049] Step S403: Based on a preset private protocol, the first raw data is encapsulated into a first private data packet and sent to the software application system; wherein, the preset private protocol is a private network communication protocol between the instrument system and the software application system.

[0050] Specifically, to address users' needs for data transmission and control of the instrument system through software applications—such as navigation input, cockpit control, and air conditioning activation—the real-time performance of the instrument system must be guaranteed. For the hardware-isolated instrument system and software application system, a proprietary protocol is designed for communication between the two systems. The instrument system encapsulates raw data into proprietary data packets using this protocol, ensuring data transmission security and effectively reducing communication latency. This data is then sent to the software application system via a persistent TCP connection, ensuring data validity and reliable transmission.

[0051] The vehicle communication method provided in this embodiment achieves hardware resource isolation by dividing the smart cockpit into independent instrument system, remote communication system, and software application system, and allocates an independent physical channel to each system, thereby improving system isolation and security. The instrument system decrypts the first encrypted data sent by the main controller to obtain remote communication data and / or software application data from other systems, enabling information transmission between hardware-isolated systems and avoiding system data leakage caused by shared memory. Furthermore, by designing a private communication protocol between the instrument system and the software application system, the decrypted first raw data is sent to the software application system, reducing inter-system communication latency and improving the real-time performance of instrument system data display and command execution.

[0052] This embodiment provides a vehicle communication method, which can be used for, for example Figure 2 The instrument system shown, such as the instrument display, etc. Figure 5 This is a flowchart of a vehicle communication method according to an embodiment of the present invention, such as... Figure 5 As shown, the process includes the following steps: Step S501: Receive the first encrypted data sent by the main controller through the first physical channel.

[0053] Specifically, before performing step S501, the following steps are performed: Step a1: Send a handshake connection request to the main controller; the handshake connection request includes a random number.

[0054] Specifically, the SPI service of the instrumentation system is used to establish a reliable connection between the instrumentation system and the main controller. For example... Figure 6 As shown, firstly, a data packet structure `tmpSendRpcPacket` is created and initialized / reset. Next, after clearing the existing data in the buffer, the random number generation function `wt_srand_128data` is called to generate a new random sequence, and the generated 128-bit random number is used as the handshake identifier.

[0055] Furthermore, following a specific format protocol, a random number is encapsulated into a handshake connection request data packet using command code 0x0400 (message identifier msgid is HAND_SHAKE_0). If encapsulation fails, an error log is recorded. After successful encapsulation of the handshake connection request data packet, the handshake connection request is sent to the main controller MCU by calling the ServerSendToMcu function; if sending fails, an error log is also recorded.

[0056] Furthermore, after the handshake connection request is successfully sent, the system checks whether the 3-second timer flag (mThreeHandTimer, which generates a 3-second timer flag every 3 seconds) exists. If it exists, the timer is stopped and the 3-second timer flag is reset. Then, the timer is started, and the HandShakeProcess function is called every 3 seconds to process the handshake response. If it does not exist, the timer is started. This embodiment uses a timer duration of 3 seconds as an example, but the timer duration can be adjusted according to actual needs.

[0057] Step a2: Receive the random number encrypted data packet returned by the main controller based on the handshake connection request. If the random number encrypted data packet is successfully verified, send encrypted response data to the main controller.

[0058] Specifically, the handshake process between the instrumentation system and the main controller MCU employs a multi-stage bidirectional verification mechanism to ensure secure and reliable communication. For example... Figure 7 As shown, firstly, the instrument system sends a 0400 handshake connection request packet to the main controller MCU. After receiving the packet, the main controller MCU parses it. If the parsing is successful, it calculates the message identifier msgid and random number of the packet and enters the switch branch.

[0059] Next, if the main controller MCU recognizes that the message identifier msgid is HAND_SHAKE_0, it returns an ACK confirmation response to the instrumentation system. Furthermore, the main controller MCU uses the encryption key to encrypt the parsed random number and encapsulates it into a 0401 data packet (random number encrypted data packet), which is then sent to the instrumentation system.

[0060] Then, see again Figure 7 After receiving the 0401 data packet (random number encrypted data packet) sent by the main controller MCU, the instrument system recognizes that the message identifier msgid is HAND_SHAKE_1, stops the timer, and then sends an ACK response confirmation to the main controller MCU.

[0061] Furthermore, the instrument system uses the AES-128 encryption algorithm to encrypt the locally stored random numbers and compares them with the data sent by the MCU for verification. For example, the instrument system decrypts the encrypted random number data packet (0401 data packet) sent by the main controller MCU to obtain a second encrypted random number, and simultaneously encrypts its own stored random number to obtain a first encrypted random number. If the first and second encrypted random numbers match, the encrypted random number data packet verification is considered successful. After successful verification, the instrument system sends encrypted response data, i.e., the 0402 data packet, to the main controller MCU.

[0062] In this embodiment, the instrument system encrypts its own stored original random number to generate a first encrypted random number. At the same time, it decrypts the received encrypted random number data packet sent by the main controller to obtain the first encrypted random number. By comparing whether the two are consistent, it can effectively verify whether the main controller holds the correct encryption key, thereby ensuring that the instrument system and the main controller at both ends of the communication link are legitimate authorized devices, improving the reliability of the identity authentication process and the system security.

[0063] Step a3: Receive the initial status data returned by the main controller based on the encrypted response data. If the initial status data is found to be valid, establish a handshake connection with the main controller.

[0064] Specifically, see again Figure 7 The MCU decrypts the received encrypted response data packet 0402, identifies the message identifier msgid as HAND_SHAKE_2, and sends an ACK confirmation. Then, the MCU sends initial status data, i.e., the 0403 data packet, to the instrument system. After the instrument system verifies the validity of the 0403 data packet, it stops the timer (stops processing the handshake response), sends an ACK confirmation to the MCU, and completes the entire handshake process. It then sets the handshake flag, starts the heartbeat timer, and enters the heartbeat timeout monitoring process.

[0065] In some embodiments, the initial state data 0403 data packet may contain display data required by the instrument system, such as vehicle status, vehicle speed, and other instrument information. The validity of the initial state data is determined by verifying whether it conforms to the data structure definition of the corresponding data type. For details, please refer to the detailed description of the relevant technology; further elaboration will not be repeated here.

[0066] In this embodiment, authentication is initiated by sending a handshake request containing a random number to the main controller. The initial verification of the main controller's identity is completed using the encrypted data packet returned by the main controller. After successful verification, encrypted response data is sent. Finally, the validity of the initial state data returned by the main controller is checked, completing the bidirectional authentication and state synchronization between the instrument system and the main controller. This achieves identity authentication and dynamic key negotiation between the communicating parties, thereby establishing a secure handshake connection and improving the reliability and integrity of the connection establishment process.

[0067] In this embodiment, during the entire handshake process between the instrument system and the main controller, a random number is encapsulated within the handshake connection request to ensure the security of the handshake. A timer mechanism is also used to guarantee the timeliness of the handshake response, establishing a reliable foundation for subsequent private data communication.

[0068] In some alternative implementations, after establishing a handshake connection, anomalies are monitored in real time through a timeout reconnection mechanism, periodic heartbeats, and a program self-protection mechanism, including the following steps: Step b1: Determine the time difference between the current timestamp and the synchronization timestamp; wherein, the synchronization timestamp is used to characterize the last communication time between the instrument system and the main controller.

[0069] Specifically, the heartbeat mechanism between the instrumentation system and the MCU employs a timed detection method to ensure the stability of the handshake connection. The heartbeat process is implemented through the SocketHeartProcess function, which is executed periodically as a timer callback. Figure 8 As shown, each time the SocketHeartProcess function is executed, the instrument system records the current timestamp and compares it with the previous synchronization timestamp to calculate the time difference. The synchronization timestamp is the last recorded communication time between the instrument system and the main controller.

[0070] Step b2: If the detected time difference exceeds the preset time difference, record the number of heartbeat failures and determine whether the number of heartbeat failures has reached the preset number.

[0071] Specifically, see again Figure 8 If the detected time difference exceeds the preset time difference (e.g., 3 seconds), the heartbeat failure count is incremented by one, and it is checked whether the currently recorded heartbeat failure count has reached the preset number (e.g., 5 times). If the preset number has not been reached, the system encapsulates and sends a heartbeat data packet (HEART_BEAT command) to the main controller MCU via the ServerSendToSocket function. If the heartbeat data packet is sent successfully, true is returned, indicating a good connection status; if the heartbeat data packet fails to be sent, the connection status is abnormal. If the time difference does not exceed the preset time difference and is within the normal range, the heartbeat counter is reset, the heartbeat failure count is reset, the reset log is recorded, and true is returned, indicating a good connection status.

[0072] Step b3: If the number of heartbeat failures reaches the preset number, re-establish the handshake connection with the main controller and reset the heartbeat failure count.

[0073] Specifically, see again Figure 8 If the number of failed heartbeats reaches the preset number, the connection is determined to be abnormal, the heartbeat timer (stop time difference recording) and socket output are automatically stopped, the handshake connection is restarted, and the heartbeat timer and the number of failed heartbeats are reset.

[0074] In this embodiment, after a successful handshake, a heartbeat monitoring mechanism is initiated to ensure the stability of subsequent communication. Simultaneously, the external handshake connection is initialized to prepare for data transmission. The entire process employs strict timeout control, managing state transitions at each stage through multiple timers and counters to ensure the real-time performance and reliability of the handshake. If any stage verification fails or times out, the system immediately terminates the handshake process, effectively preventing unauthorized access and communication anomalies, thus ensuring both communication security and stable system operation.

[0075] The entire handshake process in this embodiment includes a robust exception handling mechanism. It can automatically recover when a handshake connection anomaly is detected, and logs key states to facilitate troubleshooting. This ensures both real-time monitoring of the connection status and rapid recovery in case of anomalies, guaranteeing communication reliability and continuity.

[0076] In the above embodiments, abnormal interruptions in the communication link are detected in real time by continuously comparing the time difference between the current timestamp and the last communication timestamp. When a timeout is detected, the cumulative count of failed heartbeats is used to avoid misjudgments and frequent reconnections caused by instantaneous network fluctuations. Finally, after confirming the connection failure, a handshake reconnection is triggered to restore communication between the two ends. This improves the reliability of the instrument system in the face of interference or failures, and ensures the continuity and stability of vehicle communication.

[0077] Step S502: Receive the second private data packet sent by the software application system; parse the second private data packet based on the preset private protocol to obtain the second raw data.

[0078] In this embodiment, the data transmission process from the software application system (e.g., Android system) to the instrument system is a complete private protocol communication process. First, the software application system encapsulates the original application data, such as control commands sent by the user through the upper-layer application, into a second private data packet. For example... Figure 9 As shown, the software application system receives application data packets from the upper-layer application, parses the application data packets through data processing functions, and converts the raw application data into structured preset private protocol data objects.

[0079] Specifically, after successful parsing, the software application system checks the data packet type. If it's an acknowledgment packet (ACK), it returns directly; otherwise, it immediately sends an acknowledgment response to ensure reliable communication. During data processing, if logging is enabled, the software application system stores data packet information in a log queue, including key information such as data direction and original data, facilitating subsequent analysis and tracing.

[0080] Next, the software application system calculates message identifiers by combining command codes and sub-command codes; for example, 0x0100 represents a heartbeat data packet, and 0x2003 represents an air conditioner start command. It then preprocesses the raw application data. After preprocessing, the data is encapsulated into a data structure defined by a predefined private protocol, containing information such as data packet type, data pointer, data length, and routing identifier, resulting in a second private data packet. Finally, the encapsulated second private data packet is sent to the instrumentation system via the WTIvsAdaper singleton instance function. The entire process includes a robust error handling mechanism; any anomaly at any stage is logged to ensure the traceability and reliability of data transmission.

[0081] In some embodiments, when the instrumentation system and the software application system communicate with each other, they encapsulate the transmitted data into private data packets according to a preset private protocol. For example... Figure 10 As shown, the data structure of a private data packet mainly includes: a 2-byte data type prefix; a 1-byte routing identifier channel; a 1-byte extension flag exten. used to indicate additional attributes of the data packet, such as whether it is an ACK acknowledgment packet; a 1-byte sequence number SN, used to indicate the sending order of the data packet; a 2-byte data length Length, indicating the actual length of the data sent; N bytes of data bits Data, indicating the actual data sent, where N can be set according to actual needs; a 2-byte cyclic redundancy check (CRC) code; and optional fields, etc.

[0082] In step S502, after receiving the data packet sent by the software application system, the instrument system will parse it according to the preset private protocol to obtain the second raw data sent by the software application system.

[0083] Step S503: The second original data is encrypted into second encrypted data, and the second encrypted data is sent to the main controller through the first physical channel.

[0084] In some embodiments, a first state matrix is ​​constructed based on the second original data; a first key matrix is ​​constructed, and multiple first-round keys are generated based on the first key matrix; based on the multiple first-round keys, multiple rounds of encryption operations are performed on the first state matrix to obtain the second encrypted data.

[0085] Specifically, the encryption process can employ the AES-128 encryption algorithm, using multiple rounds of transformations to encrypt the data. For example... Figure 11As shown, firstly, the instrument system initializes the RCON counter, which is used to generate a new round key for each round during the key expansion process. The input second raw data (16 bytes of plaintext) and the 16-byte key are copied to the 4x4 first state matrix ucSig1 and the first key matrix ucKey1, respectively. Multiple first round keys are generated through the key scheduling function KeySchedule for key addition. At the start of the encryption process, the initial round key addition AddRoundKey is performed by XORing the first state matrix ucSig1 and the first key matrix ucKey1.

[0086] The main encryption loop then proceeds, performing 10 rounds (9 standard rounds and 1 final round). Each standard round executes: SubBytes (non-linear replacement of each byte in the first state matrix using an S-box); ShiftRows (circular left shift of the rows in the first state matrix); MixColumns (linear transformation of the columns in the first state matrix); and KeySchedule (key addition using the round key for the corresponding round). The final round omits the MixColumns step, performing only byte replacement, row shifts, and key addition. After all rounds are completed, the result from the first state matrix is ​​copied back to the input buffer, yielding a 16-byte encrypted result, which is the second encrypted data.

[0087] This embodiment ensures the security and reliability of encryption through multiple rounds of complex mathematical transformations. By using a variable number of rounds—the standard round and the final round—it dynamically balances security and performance, offering greater flexibility and suitability for resource-constrained environments.

[0088] This invention generates round keys for multiple rounds of encryption based on the expansion of the first key matrix, and performs multiple rounds of encryption on the second original data sent by the software application system to ensure the strength and reliability of the encryption operation. This enables end-to-end encrypted transmission of application layer data from the instrument system to the main controller, preventing data from being stolen or tampered with during transmission and ensuring the security and integrity of user commands and status information.

[0089] In the above embodiments, for the hardware-isolated instrument system and software application system, the instrument system communicates with the software application system through a proprietary protocol, and parses and encrypts the data packets sent by the software application system. This allows the data from the software application system to be forwarded to the main controller via the first physical channel between the instrument system and the main controller, achieving secure encrypted data transmission and communication between different systems. Furthermore, the proprietary protocol design significantly reduces communication latency between systems.

[0090] Step S504: Decrypt the first encrypted data to obtain the first original data; wherein, the first original data includes remote communication data and / or software application data, the remote communication data includes data sent by the remote communication system to the main controller through the second physical channel, and the software application data includes data sent by the software application system to the main controller through the third physical channel.

[0091] Specifically, step S504 includes: Step S5041: Construct a second state matrix based on the first encrypted data; construct a second key matrix; and generate multiple second-round keys based on the second key matrix.

[0092] Specifically, the decryption process can employ the AES-128 decryption algorithm, achieving data decryption through inverse transformation. For example... Figure 12 As shown, firstly, the system initializes the RCON counter and copies the first encrypted data (16 bytes of ciphertext) and the 16-byte key into the 4x4 second state matrix ucSig2 and the second key matrix ucKey2, respectively. Furthermore, at the start of decryption, the KeySchedule function performs key scheduling on the second key matrix ucKey2, pre-generating 10 rounds of second-round keys, each corresponding to a different round.

[0093] Step S5042: Based on multiple second-round keys, perform multiple rounds of decryption operations on the second state matrix to obtain the first original data; wherein, the decryption operation is the inverse process of the encryption operation.

[0094] Specifically, see again Figure 12 First, the second state matrix ucSig2 is subjected to a key addition operation, AddRoundKey. Then, the main decryption loop is entered, performing 10 rounds of inverse transformation (9 standard rounds and 1 final round). Each standard round performs: InvShiftRows (circularly shifting the rows of the second state matrix ucSig2 to the right); InvSubBytes (replacing bytes using the inverse S-box); then reinitializing the key and generating the corresponding round key, performing a key addition operation; and finally, InvMixColumns (inverse column mixing). The final round omits the inverse column mixing step, performing only inverse shift, inverse byte replacement, and key addition. After all rounds are completed, the result from the second state matrix is ​​copied back to the input buffer, yielding a 16-byte decryption result, which is the first original data. The entire process, through rigorous inverse transformation, ensures the correct data reconstruction while maintaining the security of the AES algorithm.

[0095] This embodiment generates a second-round key for multi-round decryption based on the second key matrix expansion, and reconstructs the received second encrypted data into the first original data, ensuring that the encrypted data can be uniquely and correctly restored to the original instruction or status information, ensuring reliable decryption and use of the data at the receiving end, thereby forming a data security transmission system in conjunction with the encryption process, preventing the loss of legitimate information due to the inability to decrypt, and ensuring the integrity and continuity of the intelligent cockpit system functions.

[0096] In some optional implementations, the data access permissions of the software application system are determined, and the permissions of the first original data are verified based on the data access permissions. If the permission verification of the first original data is detected to be successful, step S505 is executed.

[0097] This embodiment uses application-layer permission management and a data access whitelist mechanism to determine the data access permissions of the software application system to the instrument system, strictly restricting the user application's access permissions to sensitive vehicle data. While ensuring efficient communication, it constructs a security barrier that adapts to the characteristics of heterogeneous systems.

[0098] Step S505: Based on a preset private protocol, the first raw data is encapsulated into a first private data packet and sent to the software application system; wherein, the preset private protocol is a private network communication protocol between the instrument system and the software application system.

[0099] Specifically, the data processing flow from the instrumentation system to the software application system is a rigorous proprietary protocol communication process. For example... Figure 13 As shown, the instrument system first receives data packets from the MCU, parses the packets using a data processing function, and converts the raw data into structured private protocol data objects. Upon successful parsing, the instrument system resets the heartbeat timeout counter and checks the data packet type. For specific commands (0x19), acknowledgment packets (ACK), or empty data packets, it returns directly without further processing. For valid data packets, the system immediately sends an ACK confirmation response to ensure reliable communication.

[0100] Next, the system generates a message identifier (msgid) by combining command words and subcommand words. If it's a heartbeat packet (0x0100), it returns directly. For other valid data, the system encapsulates it into a private protocol data structure, containing information such as the message identifier (msgid), packet type, data pointer, data length, and routing identifier, obtaining the first private data packet. Then, through a WTIvsAdaper singleton instance, the first private data packet is sent to the software application system. Simultaneously, if logging is enabled, the system stores the data packet information in a log queue. Finally, the instrument system locates the corresponding processor based on the message identifier and calls its processing method to perform specific business processing. The entire process includes robust error handling and logging mechanisms to ensure the reliability and traceability of data transmission.

[0101] This invention, based on Hypervisor virtualization technology, constructs an independent partition architecture for the instrumentation system, Android system, and TBOX system, achieving hardware-level security isolation. Each partition is allocated independent computing resources and communication channels, and cross-partition data interaction is strictly restricted through access control mechanisms at the virtualization layer, allowing only authenticated communication links. By blocking unauthorized access paths at the system level, this approach ensures the real-time performance and security of critical components such as the instrumentation system while preserving the flexibility for application expansion in the Android system, thus resolving the conflict between security and functional expansion in multi-system convergence scenarios.

[0102] This invention addresses the communication security issues between instrument systems and MCUs by constructing a multi-layered protection mechanism. At the data transmission level, it employs AES encryption for end-to-end encryption to prevent information leakage. A dynamic handshake mechanism completes two-way authentication and key negotiation during communication initialization, preventing unauthorized device access. Periodic heartbeat monitoring and timeout reconnection mechanisms are introduced to monitor link status in real time and enable abnormal reconstruction. Simultaneously, a program self-protection module is deployed to verify the integrity of the communication process and monitor abnormal data in real time. In the event of an attack, the link can be disconnected, forming a comprehensive security system encompassing encrypted transmission, authentication, status monitoring, and anomaly protection, significantly improving communication reliability.

[0103] This invention addresses the cross-platform communication needs between instrument systems and Android systems by utilizing a proprietary protocol. The proprietary protocol packet employs a structured design, including a Prefix field for data type identification, a Channel field for routing control, a CRC checksum field to ensure data integrity, and a message authentication code, preventing data tampering and replay attacks. This proprietary protocol encapsulation ensures the real-time performance and accuracy of control commands. Furthermore, the use of a TCP long connection transmission method ensures data orderliness and reliability, and an event-driven mechanism enables on-demand data push, reducing resource consumption. The TBOX extends the communication link to the cloud via a vehicle-to-cloud encrypted tunnel, supporting hierarchical verification and execution of remote control commands.

[0104] This invention ensures millisecond-level response of the instrument system while being compatible with the flexible expansion of Android applications. By combining encryption algorithms, multi-layer verification and anomaly reconstruction mechanisms, it significantly improves the security, reliability and scalability of cross-system communication in the smart cockpit.

[0105] This embodiment also provides a vehicle communication device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" refers to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0106] This embodiment provides a vehicle communication device. The vehicle includes a main controller and a smart cockpit. The smart cockpit is divided into a hardware-isolated instrument system, a remote communication system, and a software application system. This device is applied to the instrument system, such as... Figure 14 As shown, the device includes: The first processing module 1401 is used to receive the first encrypted data sent by the main controller through the first physical channel; The second processing module 1402 is used to decrypt the first encrypted data to obtain the first original data; wherein, the first original data includes remote communication data and / or software application data, the remote communication data includes data sent by the remote communication system to the main controller through the second physical channel, and the software application data includes data sent by the software application system to the main controller through the third physical channel; The third processing module 1403 is used to encapsulate the first raw data into a first private data packet and send it to the software application system based on a preset private protocol; wherein, the preset private protocol is a private network communication protocol between the instrument system and the software application system.

[0107] In some optional implementations, before receiving the first encrypted data sent by the main controller through the first physical channel, the first processing module 1401 is further configured to: Send a handshake connection request to the main controller; the handshake connection request includes a random number; Receive the random number encrypted data packet returned by the main controller based on the handshake connection request. If the random number encrypted data packet is successfully verified, send encrypted response data to the main controller. Receive initial status data returned by the main controller based on encrypted response data. If the initial status data is found to be valid, establish a handshake connection with the main controller.

[0108] In some optional implementations, after receiving the handshake identifier encrypted data packet returned by the master controller based on the handshake connection request, the first processing module 1401 is further configured to: The stored random number is encrypted to obtain the first encrypted random number; The encrypted random number data packet sent by the main controller is decrypted to obtain the second encrypted random number; If the first encrypted random number and the second encrypted random number are found to be the same, the random number encrypted data packet is deemed to have passed verification.

[0109] In some alternative implementations, after establishing a handshake connection with the main controller, the first processing module 1401 is further configured to: Determine the time difference between the current timestamp and the synchronization timestamp; where the synchronization timestamp is used to characterize the last communication time between the instrumentation system and the main controller; If the detected time difference exceeds the preset time difference, record one heartbeat failure and determine whether the number of heartbeat failures has reached the preset number; If the number of failed heartbeats reaches the preset number, re-establish the handshake connection with the main controller and reset the number of failed heartbeats.

[0110] In some optional implementations, after decrypting the first encrypted data to obtain the first original data, the second processing module 1402 is further configured to: Determine the data access permissions for the software application system; Based on data access permissions, the first original data is verified for permissions. If the permission verification of the first original data is passed, the first original data is encapsulated into a first private data packet based on a preset private protocol and sent to the software application system.

[0111] In some optional implementations, the third processing module 1403 is further configured to: Receive the second private data packet sent by the software application system; The second private data packet is parsed based on a preset private protocol to obtain the second raw data. The second original data is encrypted into second encrypted data, and the second encrypted data is sent to the main controller through the first physical channel.

[0112] In some optional implementations, the third processing module 1403 is further configured to: Construct the first state matrix based on the second original data; Construct a first key matrix, and generate multiple first-round keys based on the first key matrix; Based on multiple first-round keys, multiple rounds of encryption operations are performed on the first state matrix to obtain the second encrypted data.

[0113] In some optional implementations, the second processing module 1402 is further configured to: Construct a second state matrix based on the first encrypted data; Construct a second key matrix, and generate multiple second-round keys based on the second key matrix; Based on multiple second-round keys, multiple rounds of decryption operations are performed on the second state matrix to obtain the first original data; wherein, the decryption operation is the inverse process of the encryption operation.

[0114] The vehicle communication device provided in this embodiment of the invention can execute the vehicle communication method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0115] Figure 15 This is a schematic diagram of an instrument system provided in an embodiment of the present invention.

[0116] The following is a detailed reference. Figure 15 The diagram illustrates a structural schematic suitable for implementing an instrument system according to an embodiment of the present invention. The instrument system may include a processor (e.g., a central processing unit, graphics processor, etc.) 1501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1502 or a program loaded from a memory 1508 into a random access memory (RAM) 1503. The RAM 1503 also stores various programs and data required for the operation of the instrument system. The processor 1501, ROM 1502, and RAM 1503 are interconnected via a bus 1504. An input / output (I / O) interface 1505 is also connected to the bus 1504.

[0117] Typically, the following devices can be connected to I / O interface 1505: input devices 1506 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 1507 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; memory devices 1508 including, for example, magnetic tape, hard disk, etc.; and communication devices 1509. Communication device 1509 allows the instrument system to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 15 An instrument system with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0118] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 1509, or installed from a memory 1508, or installed from a ROM 1502. When the computer program is executed by the processor 1501, it performs the functions defined in the vehicle communication method of the embodiments of the present invention.

[0119] Figure 15 The instrument system shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0120] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the vehicle communication method shown in the above embodiments is implemented.

[0121] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0122] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A vehicle communication method, characterized in that, The vehicle includes a main controller and an intelligent cockpit, which is divided into a hardware-isolated instrument system, a remote communication system, and a software application system. The method is applied to the instrument system, and the method includes: Receive the first encrypted data sent by the main controller through the first physical channel; The first encrypted data is decrypted to obtain the first original data; wherein, the first original data includes remote communication data and / or software application data, the remote communication data includes data sent by the remote communication system to the main controller through a second physical channel, and the software application data includes data sent by the software application system to the main controller through a third physical channel; Based on a preset private protocol, the first raw data is encapsulated into a first private data packet and sent to the software application system; wherein, the preset private protocol is a private network communication protocol between the instrument system and the software application system.

2. The vehicle communication method according to claim 1, characterized in that, The method further includes: Receive the second private data packet sent by the software application system; The second private data packet is parsed based on a preset private protocol to obtain the second raw data. The second original data is encrypted into second encrypted data, and the second encrypted data is sent to the main controller through the first physical channel.

3. The vehicle communication method according to claim 2, characterized in that, Before receiving the first encrypted data sent by the main controller through the first physical channel, the method further includes: Send a handshake connection request to the main controller; the handshake connection request includes a random number; Receive the random number encrypted data packet returned by the main controller based on the handshake connection request; if the random number encrypted data packet is detected to be verified, send encrypted response data to the main controller. Receive initial state data returned by the main controller based on the encrypted response data. If the initial state data is found to be valid, establish a handshake connection with the main controller.

4. The vehicle communication method according to claim 3, characterized in that, After receiving the encrypted handshake identifier data packet returned by the master controller based on the handshake connection request, the method further includes: The stored random number is encrypted to obtain the first encrypted random number; The encrypted random number data packet sent by the main controller is decrypted to obtain a second encrypted random number; If the first encrypted random number and the second encrypted random number are found to be the same, the encrypted data packet of the random number is deemed to have passed verification.

5. The vehicle communication method according to claim 3, characterized in that, After establishing a handshake connection with the main controller, the method further includes: Determine the time difference between the current timestamp and the synchronization timestamp; wherein the synchronization timestamp is used to characterize the last communication time between the instrument system and the main controller; If the time difference is detected to exceed the preset time difference, record one heartbeat failure count and determine whether the heartbeat failure count has reached the preset number. If the number of failed heartbeats reaches a preset number, the handshake connection with the main controller is re-established, and the number of failed heartbeats is reset.

6. The vehicle communication method according to any one of claims 1-5, characterized in that, After decrypting the first encrypted data to obtain the first original data, the method further includes: Determine the data access permissions for the software application system; Based on the data access permissions, the first original data is verified for permissions. If the permission verification of the first original data is passed, the first original data is encapsulated into a first private data packet based on a preset private protocol and sent to the software application system.

7. The vehicle communication method according to any one of claims 2-5, characterized in that, The step of encrypting the second original data into second encrypted data includes: Construct a first state matrix based on the second original data; Construct a first key matrix, and generate multiple first-round keys based on the first key matrix; Based on the multiple first-round keys, multiple rounds of encryption operations are performed on the first state matrix to obtain the second encrypted data.

8. The vehicle communication method according to claim 7, characterized in that, The process of decrypting the first encrypted data to obtain the first original data includes: Construct a second state matrix based on the first encrypted data; Construct a second key matrix, and generate multiple second-round keys based on the second key matrix; Based on the multiple second-round keys, multiple rounds of decryption operations are performed on the second state matrix to obtain the first original data; wherein the decryption operation is the inverse process of the encryption operation.

9. A vehicle communication device, characterized in that, The vehicle includes a main controller and an intelligent cockpit, which is divided into a hardware-isolated instrument system, a remote communication system, and a software application system. The device is used in the instrument system, and the device includes: The first processing module is used to receive the first encrypted data sent by the main controller through the first physical channel; The second processing module is used to decrypt the first encrypted data to obtain the first original data; wherein the first original data includes remote communication data and / or software application data, the remote communication data includes data sent by the remote communication system to the main controller through a second physical channel, and the software application data includes data sent by the software application system to the main controller through a third physical channel; The third processing module is used to encapsulate the first raw data into a first private data packet and send it to the software application system based on a preset private protocol; wherein, the preset private protocol is a private network communication protocol between the instrument system and the software application system.

10. A vehicle, characterized in that, The vehicle includes a main controller and an intelligent cockpit, which is divided into a hardware-isolated instrument system, a remote communication system, and a software application system. The instrument system includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the vehicle communication method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the vehicle communication method according to any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the vehicle communication method according to any one of claims 1 to 8.

Images