An OTA-based vehicle data upgrade method, device and in-vehicle terminal

Abstract

The present invention discloses an OTA-based vehicle data upgrade method, device and in-vehicle terminal for a first in-vehicle terminal, including: obtaining a vehicle upgrade data packet; loading the vehicle upgrade data packet into a target message based on a preset protocol; starting in response to an OTA upgrade instruction, sending a request message to a second in-vehicle terminal, and starting a first DPDK instruction; based on the first DPDK instruction, sending the target message to the second in-vehicle terminal. When the first in-vehicle terminal is secondarily developed based on the DPDK data plane development kit and integrated into the vehicle gateway, when there is a vehicle-wide OTA upgrade, the vehicle gateway of the first in-vehicle terminal directly operates on the in-vehicle network card through the OTA program to call the DPDK kit, and can bypass the way of processing data packets by the linux kernel protocol stack for the vehicle upgrade data packet, which can solve the problems of time-consuming flashing of the first in-vehicle terminal and low vehicle-wide upgrade efficiency to a certain extent, reduce the waiting time of the vehicle owner for the upgrade, and enhance the user experience.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle data upgrade of OTA (Over-the-Air Technology), and specifically relates to a method, device and in-vehicle terminal for vehicle data upgrade based on OTA. Background Art

[0002] With the rapid development of computer control, entertainment systems, and communication network technologies, the vehicle field has also incorporated diverse entertainment devices and communication devices. The functions of the electronic control units installed are increasing, and thus vehicle data information has become increasingly complex. Therefore, the OTA remote upgrade technology can be continuously expanded in in-vehicle terminals, vehicle controllers, or the entire vehicle, and continuously optimize the existing functions of the vehicle to enhance the user experience.

[0003] In related technologies, the vehicle data upgrade of the entire vehicle based on vehicle data is divided into online upgrade and offline upgrade. For online upgrade, it generally communicates with the TBOX through the cloud, and issues the upgrade package to the TBOX or gateway in the vehicle. The vehicle-mounted gateway uses the DOIP protocol based on Ethernet to transmit through the kernel protocol stack to the network card, and the network card sends the upgrade package to each ECU, and each ECU will be upgraded in sequence. Or, for offline upgrade, an exclusive tool for vehicle after-sales is used to upgrade through the OBD port or USB port. Currently, online upgrade is generally adopted for the entire vehicle upgrade.

[0004] As Figure 1 shown, it is a schematic diagram of online upgrade. When the upgrade package reaches the in-vehicle gateway, the OTA program assembles the upgrade package data message according to the DOIP protocol, and sends the message through the socket interface to the kernel TCP / IP protocol stack and then to the network card. However, the DOIP protocol is based on the traditional TCP / IP protocol stack, and the sending and receiving of messages both involve the linux kernel protocol stack. Since the kernel protocol stack itself has problems in processing data packets such as interrupt handling, memory copying, context switching, locality failure, and memory management issues, when a large number of data packets arrive in the network, it will generate frequent hardware interrupt requests, continuous switching between the kernel mode and the user mode, and multiple memory copies, resulting in increased system consumption, decreased system performance, increased flashing time, and low vehicle upgrade efficiency. Summary of the Invention

[0005] Therefore, the technical problem to be solved by the present invention is to overcome the problem in the prior art that the system consumption increases, the system performance decreases, the flashing time increases, and the vehicle upgrade efficiency is low due to the data processing problems of the kernel protocol stack itself in online upgrade, so as to provide a method, device and in-vehicle terminal for vehicle data upgrade based on OTA.

[0006] According to a first aspect, an embodiment of the present invention discloses a method for vehicle data upgrade based on OTA, which is used for a first in-vehicle terminal, and includes the following steps:

[0007] Obtain a vehicle upgrade data packet;

[0008] Based on a preset protocol, load the vehicle upgrade data packet into a target message;

[0009] In response to the start of the OTA upgrade instruction, send a request message to the second vehicle-mounted terminal and start the first DPDK instruction;

[0010] Based on the first DPDK instruction, send the target message to the second vehicle-mounted terminal.

[0011] Combined with the first aspect, in an implementation manner of the first aspect, the first DPDK instruction is generated through the sending port of the first vehicle-mounted terminal.

[0012] Combined with the first aspect, in an implementation manner of the first aspect, send the target message to the second vehicle-mounted terminal through a network card.

[0013] Combined with the first aspect, in an implementation manner of the first aspect, based on the Ethernet TCP / IP protocol stack, send the request message to the second vehicle-mounted terminal.

[0014] By implementing the above implementation manner of the first aspect, secondary development is carried out on the first vehicle-mounted terminal based on the DPDK data plane development kit and integrated into the vehicle gateway. When there is a vehicle-wide OTA upgrade, the vehicle gateway of the first vehicle-mounted terminal directly operates on the in-vehicle network card through the OTA program, which can bypass the way of processing data packets by the linux kernel protocol stack, and transmit the vehicle upgrade data packet, which can solve the problems of time-consuming flashing of the first vehicle-mounted terminal and low vehicle-wide upgrade efficiency to a certain extent, reduce the waiting time of the vehicle owner for the upgrade, and enhance the user experience.

[0015] According to the second aspect, an OTA-based vehicle data upgrade method is also disclosed in an embodiment of the present invention for a second vehicle-mounted terminal, including the following steps:

[0016] Receive a request message sent by the first vehicle-mounted terminal;

[0017] Reply to the first vehicle-mounted terminal with an acknowledgement message;

[0018] In response to the start of the OTA upgrade instruction, start the second DPDK instruction;

[0019] Based on the second DPDK instruction, receive the target message sent by the first vehicle-mounted terminal;

[0020] When verifying that the target message verification is normal, perform an upgrade action according to the target message.

[0021] In combination with the second aspect, in one implementation of the second aspect, the second DPDK instruction is started through the receiving port of the second vehicle-mounted terminal.

[0022] By implementing the above implementation of the first aspect, when the second vehicle-mounted terminal is secondarily developed based on the DPDK data plane development kit and integrated into the vehicle gateway, when there is a vehicle-wide OTA upgrade, the second vehicle-mounted terminal directly operates on the in-vehicle network card by calling the DPDK kit through the OTA program, and can bypass the way of processing data packets by the linux kernel protocol stack to transmit the vehicle upgrade data packets, which can solve the problem of time-consuming flashing of the second vehicle-mounted terminal to a certain extent, reduce the waiting time of the vehicle owner for the upgrade, and enhance the user experience.

[0023] According to the third aspect, an OTA-based vehicle data upgrade device for the first vehicle-mounted terminal is further disclosed in an embodiment of the present invention, including the following modules:

[0024] An acquisition module, configured to acquire vehicle upgrade data packets;

[0025] A message loading module, configured to load the vehicle upgrade data packets into target messages based on a preset protocol;

[0026] A first start module, configured to start in response to an OTA upgrade instruction, send a request message to the second vehicle-mounted terminal, and start a first DPDK instruction;

[0027] A sending module, configured to send the target messages to the second vehicle-mounted terminal based on the first DPDK instruction.

[0028] According to the fourth aspect, an OTA-based vehicle data upgrade device for the second vehicle-mounted terminal is further disclosed in an embodiment of the present invention, including the following modules:

[0029] A first receiving module, configured to receive a request message sent by the first vehicle-mounted terminal;

[0030] A message reply module, configured to reply an acknowledgment message to the first vehicle-mounted terminal;

[0031] A second start module, configured to start in response to an OTA upgrade instruction and start a second DPDK instruction;

[0032] A second receiving module, configured to receive the target messages sent by the first vehicle-mounted terminal based on the second DPDK instruction;

[0033] A message verification module, configured to execute an upgrade action according to the target messages when it is verified that the target messages are verified normally.

[0034] According to a fifth aspect, an embodiment of the present invention further discloses a computer-readable storage medium storing computer instructions for causing a computer to execute the OTA-based vehicle data upgrade method described in the first aspect or any implementation manner of the first aspect or the second aspect or any implementation manner of the second aspect.

[0035] According to a sixth aspect, an embodiment of the present invention further discloses an in-vehicle terminal, including: 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 execute the OTA-based vehicle data upgrade method described in the first aspect or any implementation manner of the first aspect or the second aspect or any implementation manner of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the specific implementation manners of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific implementation manners or the prior art. Obviously, the drawings in the following description are some implementation manners of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0037] Figure 1 It is a schematic diagram of in-vehicle online upgrade for traditional vehicle OTA;

[0038] Figure 2 It is a schematic diagram of in-vehicle upgrade for vehicle OTA;

[0039] Figure 3 It is a flowchart of a specific example of the OTA-based vehicle data upgrade method in an embodiment of the present invention;

[0040] Figure 4 It is a flowchart of another specific example of the OTA-based vehicle data upgrade method in an embodiment of the present invention;

[0041] Figure 5 It is a schematic diagram of in-vehicle online upgrade for vehicle OTA in an embodiment of the present invention;

[0042] Figure 6 It is a schematic diagram of interaction between a first in-vehicle terminal and a second in-vehicle terminal in an embodiment of the present invention;

[0043] Figure 7 It is a structural block diagram of an OTA-based vehicle data upgrade device in an embodiment of the present invention;

[0044] Figure 8 It is another structural block diagram of an OTA-based vehicle data upgrade device in an embodiment of the present invention;

[0045] Figure 9 This is a schematic diagram of the hardware of the vehicle-mounted terminal in the embodiment of the present invention. Detailed implementation manners

[0046] Next, the technical solution of the present invention will be clearly and completely described in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0047] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation to the present invention. In addition, the terms "first", "second", and "third" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance.

[0048] In the description of the present invention, it should be noted that unless otherwise clearly specified and limited, the terms "installation", "connection", and "connection" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium, and it can also be the communication inside two elements. It can be a wireless connection or a wired connection. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific situations.

[0049] In addition, the technical features involved in different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0050] The embodiment of the present invention discloses an OTA-based vehicle data upgrade method for a first vehicle-mounted terminal. The first vehicle-mounted terminal can be a vehicle-mounted gateway or other types of vehicle-mounted terminals. In this embodiment, the first vehicle-mounted terminal is taken as an example of a vehicle-mounted gateway, as Figure 2 shown, the method includes the following steps:

[0051] Step S21: Obtain a vehicle upgrade data packet.

[0052] For example: The vehicle upgrade data packet can be the vehicle upgrade data packets of different functional modules on the entire vehicle. The vehicle upgrade data packet is first authenticated by the OTA cloud node and the vehicle terminal TBOX through the PKI system, and the encrypted vehicle upgrade data packet is pushed to the vehicle terminal TBOX using an encrypted channel. The vehicle terminal TBOX decrypts the vehicle upgrade data packet and performs authenticity and integrity verification. After the verification passes, the decrypted vehicle upgrade data packet is transmitted to the in-vehicle gateway through the Ethernet protocol. If the vehicle terminal TBOX is transmitted to the in-vehicle gateway in a transparent transmission mode, the decryption verification operation is performed at the in-vehicle gateway. Therefore, the vehicle upgrade data packet is obtained from the vehicle terminal TBOX. As Figure 3 shown, it is a schematic diagram of in-vehicle upgrade for the entire vehicle OTA. Therefore, in step S21, it can be that the second in-vehicle terminal obtains the vehicle upgrade data packet sent from the vehicle terminal TBOX.

[0053] Step S22: Based on a preset protocol, load the vehicle upgrade data packet into a target message.

[0054] In an alternative embodiment, the preset protocol is the DOIP protocol. For example: When the second in-vehicle terminal is the in-vehicle gateway, it receives the vehicle upgrade data packet and saves it locally, and at the same time calls the DOIP protocol packet assembly tool to assemble the vehicle upgrade data packet into a target message according to the specified format.

[0055] Step S23: In response to the start of the OTA upgrade instruction, send a request message to the second in-vehicle terminal and start the first DPDK instruction.

[0056] In a specific embodiment, based on the Ethernet TCP / IP protocol stack, the request message is sent to the second in-vehicle terminal.

[0057] The in-vehicle gateway of the second in-vehicle terminal receives the vehicle upgrade data packet and saves it locally, and sends an upgrade message based on the Ethernet TCP / IP protocol stack through the OTA upgrade program. The upgrade message is a request message and sends each request message to the second in-vehicle terminal.

[0058] In a specific embodiment, the first DPDK instruction is generated through the sending port of the first in-vehicle terminal.

[0059] DPDK (Data Plane Development Kit), mainly runs based on the Linux system, and is a set of function libraries and drivers for fast packet processing. Since this technology bypasses the Linux kernel protocol stack's processing of packets and implements a data plane in the user space to send, receive, and process packets. Therefore, it can greatly improve data processing performance and throughput and improve the working efficiency of data plane applications.

[0060] Since the current vehicle upgrade mainly relies on offline USB upgrade and online OTA vehicle upgrade. However, as software functions become more and more complex, the size of software update packages is also increasing accordingly. Nevertheless, in-vehicle OTA data transmission still does not bypass the kernel protocol stack. All these factors lead to an increasingly long vehicle upgrade time, bringing many inconveniences to people's travel. For example: in Figure 1 When performing an online upgrade, the sending and receiving of messages both involve the linux kernel protocol stack. Due to problems such as interrupt handling, memory copying, context switching, locality failure, and memory management issues in the kernel protocol stack itself when processing data packets, when a large number of data packets arrive in the network, frequent hardware interrupt requests, continuous switching between the kernel mode and the user mode, and multiple memory copies will occur, resulting in increased system consumption, decreased system performance, increased flashing time, and low vehicle upgrade efficiency. Although there are relevant mitigation measures currently, such as using differential upgrade, by comparing the differences between the new and old firmware, the cloud only pushes the differential firmware to reduce the size of the upgrade package and thus reduce the time spent on the upgrade. However, it still cannot solve the performance loss problem caused by the kernel mode participating in data packet transmission.

[0061] Therefore, in the technical field of vehicle OTA vehicle upgrade, in view of the problems that software functions are becoming more and more complex, the size of software update packages is also increasing accordingly, yet in-vehicle OTA data transmission still does not bypass the kernel protocol stack, and all these factors lead to an increasingly long vehicle upgrade time, bringing many inconveniences to people's travel, the first DPDK instruction is applied to the sending port of the first vehicle terminal, bypassing the operation processing of the kernel protocol stack, saving the upgrade operation process, and still being able to ensure the successful transmission of the target message to achieve the purpose of quickly improving the vehicle data upgrade efficiency.

[0062] Step S24: Based on the first DPDK instruction, send the target message to the second vehicle terminal.

[0063] In a specific implementation manner, the target message is sent to the second vehicle terminal through the network card.

[0064] For example: The in-vehicle gateway OTA upgrade program of the second vehicle terminal starts the DPDK sending port, that is, the first DPDK instruction mentioned above. The DOIP protocol packet assembly tool sends the target message of the assembled relevant vehicle upgrade data packet to the DPDK sending port. The first DPDK program instruction of the DPDK sending port bypasses the kernel protocol stack and directly sends the target message to the communication queue. The network card of the in-vehicle gateway copies the target message in the communication queue to the network card through DMA operation and sends it to the second vehicle terminal.

[0065] Such as Figure 3As shown in the figure, it is a specific schematic diagram of the OTA-based vehicle data upgrade method in the embodiments of the present invention. By executing steps S21 - S24, the first in-vehicle terminal is secondarily developed based on the DPDK data plane development kit and integrated into the vehicle gateway. When there is a vehicle-wide OTA upgrade, the vehicle gateway of the first in-vehicle terminal directly operates on the in-vehicle network card through the OTA program to call the DPDK kit, and can bypass the way of processing data packets by the linux kernel protocol stack to transmit vehicle upgrade data packets, which can solve the problem of time-consuming flashing of the first in-vehicle terminal to a certain extent, reduce the waiting time of the vehicle owner for the upgrade, and enhance the user experience. At the same time, with the continuous enrichment of vehicle-wide functions, the data packets processed by the vehicle gateway in the future will be more and more. Applying the present invention can also alleviate the problem of insufficient gateway concurrency.

[0066] Based on the same concept, the embodiments of the present invention also disclose an OTA-based vehicle data upgrade method for a second in-vehicle terminal, and the second in-vehicle terminal may be each vehicle-mounted ECU or other types of in-vehicle terminals, such as Figure 4 As shown, the method includes the following steps:

[0067] Step S41: Receive a request message sent by the first in-vehicle terminal.

[0068] Step S42: Reply an acknowledgment message to the first in-vehicle terminal.

[0069] Step S43: In response to the start of the OTA upgrade instruction, start the second DPDK instruction.

[0070] In a specific implementation, the second DPDK instruction is started through the receiving port of the second in-vehicle terminal.

[0071] Step S44: Based on the second DPDK instruction, receive the target message sent by the first in-vehicle terminal.

[0072] Step S45: When it is verified that the target message checksum is normal, execute the upgrade action according to the target message.

[0073] For example: Taking the second terminal as an example of each ECU, after each ECU receives the request message, it replies to the in-vehicle gateway of the first in-vehicle terminal with an acknowledgment message to confirm receipt, and starts the OTA upgrade program. The DPDK receiving port application is called through the OTA upgrade program to prepare for receiving the upgrade package, and at the same time, the DOIP protocol unpacking tool is started. When the target message arrives at the network card of each ECU, the ECU network card copies the target message from the network card to the communication queue through DMA operation. The DPDK receiving port sequentially receives the target message from the communication queue and sends the target message to the DOIP protocol unpacking tool. The DOIP protocol unpacking tool parses the received target message and stores the parsed target message locally. Finally, after the target message passes the ECU integrity check without abnormalities, it can be upgraded normally.

[0074] The OTA-based vehicle data upgrade method in the embodiments of the present invention, as Figure 5 shown, by executing the above steps S41-step S42, secondary development is carried out on the basis of the DPDK data plane development kit at the second in-vehicle terminal and integrated on the in-vehicle gateway. When there is a vehicle-wide OTA upgrade, the second in-vehicle terminal directly operates on the in-vehicle network card by calling the DPDK kit through the OTA program, and can bypass the way of the Linux kernel protocol stack to process data packets for the vehicle upgrade data packets, which solves the problem of time-consuming flashing of the second in-vehicle terminal to a certain extent, reduces the waiting time of the vehicle owner for the upgrade, and enhances the user experience. Transmitting the target message to each second in-vehicle terminal not only solves the problem of insufficient performance when a large number of data packets in the vehicle are forwarded and transmitted through the gateway, but also solves the problem of low data transmission efficiency of the traditional in-vehicle gateway through the Linux kernel protocol stack.

[0075] As Figure 6 shown, it is a schematic diagram of the mutual interaction between the first in-vehicle terminal and the second in-vehicle terminal.

[0076] The DPDK data plane development kit (DPDK, Data Plane Development Kit) is developed by multiple companies such as 6WIND and Intel, mainly runs based on the Linux system, and is a collection of function libraries and drivers for fast data packet processing. Since this technology bypasses the process of the Linux kernel protocol stack to process data packets, a data plane is implemented in the user space to receive, send, and process data packets.

[0077] In the OTA-based vehicle data upgrade method according to the embodiments of the present invention, a Data Plane Development Kit (DPDK) is mainly integrated on the first vehicle-mounted terminal and the second vehicle-mounted terminal. The DPDK working mode is divided into setting a first DPDK instruction through a sending port server on the first vehicle-mounted terminal (vehicle gateway), starting the first DPDK instruction, and sending the target message of the vehicle upgrade data packet to other second vehicle-mounted terminals through the network card. On the second vehicle-mounted terminal (each ECU), a second DPDK instruction is set through a receiving port server. When there is a vehicle-wide upgrade request, the second DPDK instruction is started to receive data from the upstream and store it locally. DPDK is a function library and driver set for fast data packet processing, bypassing the Linux kernel protocol stack's processing of data packets and implementing a data plane in the user space to send, receive, and process data packets. Therefore, it can greatly improve data processing performance and throughput and improve the working efficiency of data plane applications.

[0078] Based on the same concept, the embodiments of the present invention also disclose an OTA-based vehicle data upgrade device for the first vehicle-mounted terminal, such as Figure 7 shown, including the following modules:

[0079] An acquisition module 71, configured to acquire a vehicle upgrade data packet;

[0080] A message loading module 72, configured to load the vehicle upgrade data packet into a target message based on the DOIP protocol;

[0081] A first startup module 73, configured to start in response to an OTA upgrade instruction, send a request message to the second vehicle-mounted terminal, and start the first DPDK instruction;

[0082] A sending module 74, configured to send the target message to the second vehicle-mounted terminal based on the first DPDK instruction.

[0083] In a specific implementation manner, the first DPDK instruction is generated through the sending port of the first vehicle-mounted terminal.

[0084] In a specific implementation manner, the target message is sent to the second vehicle-mounted terminal through the network card.

[0085] In a specific implementation manner, the request message is sent to the second vehicle-mounted terminal based on the Ethernet TCP / IP protocol stack.

[0086] Based on the same concept, the embodiments of the present invention also provide an OTA-based vehicle data upgrade device for the second vehicle-mounted terminal, such as Figure 8 shown, including the following modules:

[0087] A first receiving module 81, configured to receive the request message sent by the first vehicle-mounted terminal;

[0088] A message reply module 82, configured to reply an acknowledgement message to the first vehicle-mounted terminal;

[0089] A second startup module 83, configured to start in response to an OTA upgrade instruction and start a second DPDK instruction;

[0090] A second receiving module 84, configured to receive a target message sent by the first vehicle-mounted terminal based on the second DPDK instruction;

[0091] A message verification module 85, configured to execute an upgrade action according to the target message after verifying that the target message is verified normally.

[0092] An embodiment of the present invention further provides a vehicle-mounted terminal, as Figure 9 shown. The vehicle-mounted terminal may include a processor 91 and a memory 92. The processor 91 and the memory 92 may be connected through a bus or other means. Figure 9 Taking the connection through the bus as an example.

[0093] The processor 91 may be a central processing unit (CPU). The processor 91 may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. chips, or a combination of the above types of chips.

[0094] The memory 92, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 91 executes various functional applications and data processing of the processor by running the non-transitory software programs, instructions, and modules stored in the memory 92, that is, implements the OTA-based vehicle data upgrade method in the above embodiments.

[0095] The memory 92 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created by the processor 91, etc. In addition, the memory 92 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory 92 optionally includes a memory remotely disposed relative to the processor 91, and these remote memories can be connected to the processor 91 through a network. Examples of the above-mentioned network include but are not limited to the power grid, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0096] The one or more modules are stored in the memory 92 and, when executed by the processor 91, execute the OTA-based vehicle data upgrade method in the embodiments shown in the drawings.

[0097] Specific details of the above computer device can be understood by referring to the corresponding related descriptions and effects in the embodiments shown in the drawings, and will not be elaborated here.

[0098] Those skilled in the art can understand that all or part of the processes in the above method embodiments can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD), etc.; the storage medium can also include a combination of the above types of memories.

[0099] Obviously, the above embodiments are merely examples for clear illustration and not limitations on the implementation manners. For those of ordinary skill in the art, other different forms of changes or variations can be made based on the above description. It is not necessary and impossible to list all implementation manners here. The obvious changes or variations derived therefrom are still within the protection scope of the present invention.

Claims

1. A vehicle data upgrade method based on OTA, characterized in that, For a first vehicle terminal, it includes the following steps: Obtain a vehicle upgrade data packet; Based on a preset protocol, load the vehicle upgrade data packet into a target message; Upon receiving an OTA upgrade instruction, send a request message to a second vehicle terminal and start a first DPDK instruction; Based on the first DPDK instruction, send the target message to the second vehicle terminal, so that when the second vehicle terminal verifies that the target message is normal, it performs an upgrade action according to the target message; The in-vehicle gateway OTA upgrade program of the second vehicle terminal starts the DPDK sending port, that is, the above-mentioned first DPDK instruction. The DOIP protocol packet assembly tool sends the target message of the assembled relevant vehicle upgrade data packet to the DPDK sending port. The first DPDK program instruction of the DPDK sending port bypasses the kernel protocol stack and directly sends the target message to the communication queue. The network card of the in-vehicle gateway copies the target message in the communication queue to the network card through DMA operation and sends it to the second vehicle terminal.

2. The OTA-based vehicle data upgrade method according to claim 1, wherein The first DPDK instruction is generated through the sending port of the first vehicle terminal.

3. The OTA-based vehicle data upgrade method according to claim 1, wherein Send the target message to the second vehicle terminal through the network card.

4. The OTA-based vehicle data upgrade method according to claim 1, wherein Based on the Ethernet TCP / IP protocol stack, send the request message to the second vehicle terminal.

5. A vehicle data upgrade method based on OTA, characterized in that, For a second vehicle terminal, it includes the following steps: Receive a request message sent by the first vehicle terminal; Reply with an acknowledgement message to the first vehicle terminal; Upon receiving an OTA upgrade instruction, start a second DPDK instruction; Based on the second DPDK instruction, receive the target message sent by the first vehicle terminal; When verifying that the target message is verified to be normal, perform an upgrade action according to the target message; After each ECU of the second vehicle terminal receives the request message, it replies with an acknowledgement message to the in-vehicle gateway of the first vehicle terminal to confirm receipt and starts the OTA upgrade program. The DPDK receiving port application is called through the OTA upgrade program to prepare to receive the upgrade package. At the same time, the DOIP protocol unpacking tool is started. When the target message arrives at the network card of each ECU, the ECU network card copies the target message from the network card to the communication queue through DMA operation. The DPDK receiving port sequentially receives the target message from the communication queue and sends the target message to the DOIP protocol unpacking tool. The DOIP protocol unpacking tool parses the received target message and stores the parsed target message locally.

6. The OTA-based vehicle data upgrade method according to claim 5, characterized in that, Start the second DPDK instruction through the receiving port of the second vehicle terminal.

7. An OTA-based vehicle data upgrade device, characterized in that, For a first vehicle terminal, it includes the following modules: An obtaining module, configured to obtain a vehicle upgrade data packet; A message loading module, configured to load the vehicle upgrade data packet into a target message based on a preset protocol; A first starting module, configured to start upon receiving an OTA upgrade instruction, send a request message to a second vehicle terminal, and start a first DPDK instruction; A sending module, configured to send the target message to the second vehicle terminal based on the first DPDK instruction, so that when the second vehicle terminal verifies that the target message is normal, it performs an upgrade action according to the target message; The in-vehicle gateway OTA upgrade program of the second in-vehicle terminal starts the DPDK sending port, i.e., the above-mentioned first DPDK instruction. The DOIP protocol packet assembly tool sends the target message of the assembled relevant vehicle upgrade data packet to the DPDK sending port. The first DPDK program instruction of the DPDK sending port bypasses the kernel protocol stack and directly sends the target message to the communication queue. The network card of the in-vehicle gateway copies the target message in the communication queue to the network card through DMA operation and sends it to the second in-vehicle terminal.

8. An OTA-based vehicle data upgrade device, characterized in that For a second in-vehicle terminal, it includes the following modules: A first receiving module, configured to receive a request message sent by a first in-vehicle terminal; A message reply module, configured to reply an acknowledgement message to the first in-vehicle terminal; A second startup module, configured to start in response to an OTA upgrade instruction and start a second DPDK instruction; A second receiving module, configured to receive a target message sent by the first in-vehicle terminal based on the second DPDK instruction; A message verification module, configured to execute an upgrade action according to the target message when it is verified that the target message checksum is normal; After each ECU of the second in-vehicle terminal receives the request message, it replies an acknowledgement message to the in-vehicle gateway of the first in-vehicle terminal to confirm receipt and starts the OTA upgrade program. The OTA upgrade program calls the DPDK receiving port application to prepare to receive the upgrade package. At the same time, it starts the DOIP protocol unpacking tool. When the target message arrives at the network card of each ECU, the ECU network card copies the target message from the network card to the communication queue through DMA operation. The DPDK receiving port sequentially receives the target message from the communication queue and sends the target message to the DOIP protocol unpacking tool. The DOIP protocol unpacking tool parses the received target message and stores the parsed target message locally.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the OTA-based vehicle data upgrade method according to any one of claims 1 to 6.

10. A vehicle-mounted terminal, characterized in that, It 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 execute the OTA-based vehicle data upgrade method according to any one of claims 1 to 6.

Images