Vehicle-mounted controller firmware upgrading method and related equipment

Abstract

The invention discloses a vehicle-mounted controller firmware upgrading method and related equipment, and relates to the technical field of new energy vehicles, the method is applied to a cloud server, the cloud server communicates with a vehicle-mounted terminal of a target vehicle, and the vehicle-mounted terminal comprises an upgrading module and a plurality of embedded gateways. The upgrading module is connected with each embedded gateway through a single Ethernet communication link. The method comprises the following steps: acquiring a parallel flashing matrix; for each target parallel flashing node in the parallel flashing matrix, generating a corresponding target parallel upgrading sequence; and sending the target parallel upgrading sequence corresponding to each target parallel flashing node to an upgrading module. According to the method, the parallel flash matrix and the upgrade sequence are generated through the cloud and are executed in parallel by the upgrade module, so that efficient parallel firmware upgrade of the plurality of controllers is realized under the condition of not increasing vehicle-mounted hardware resources, the upgrade efficiency can be improved, and the whole vehicle upgrade time can be shortened.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of new energy vehicles, and more particularly to a vehicle-mounted controller firmware upgrading method and related equipment. BACKGROUND

[0002] With the continuous development of intelligent networked vehicles, automatic driving and vehicle electronic and electrical architecture, the number and functions of vehicle control units (VCU) are increasing, and the demand for software maintenance and remote upgrading (FOTA, Firmware Over-The-Air) of the control system of the vehicle is continuously growing. FOTA technology can realize remote updating of controller firmware without disassembling hardware, and is an important means to ensure vehicle function safety, improve system performance and repair software defects. In particular, in the new generation of centralized or regional centralized electronic architecture, multiple controllers need to communicate and interact data through Ethernet gateways across network segments.

[0003] In related technologies, the firmware upgrade of the vehicle-mounted controller usually adopts a sequential or single-node upgrade scheme, that is, the firmware is transmitted and written to the controllers connected in sequence through the gateway. This has the problems of low upgrade efficiency and long total time. In particular, when the vehicle contains multiple gateways and a large number of controllers, the upgrade process often requires a long time window, which is difficult to meet the needs of rapid maintenance of the whole vehicle. The scheme to support multiple nodes for simultaneous upgrade usually requires the gateway to have high computing and communication capabilities, which strongly depends on hardware resources and is not suitable for embedded Ethernet gateways and vehicle-mounted controllers that only support single Ethernet communication sockets. That is, there are technical problems of low efficiency of vehicle-mounted controller firmware upgrade, insufficient resource utilization, and inability to implement parallel upgrade of multiple controllers under an embedded gateway architecture in the prior art. SUMMARY

[0004] A series of simplified concepts are introduced in the summary part of the present application, which will be further described in detail in the specific embodiment part. The summary part of the present application does not mean to try to limit the key features and necessary technical features of the claimed technical solution, and even less to determine the protection scope of the claimed technical solution.

[0005] The vehicle-mounted controller firmware upgrading method and related equipment provided by the present application can generate a parallel writing matrix and an upgrade sequence through the cloud and execute them in parallel by the upgrade module, realizing efficient parallel firmware upgrade of multiple controllers without increasing vehicle hardware resources, which can improve the upgrade efficiency and shorten the whole vehicle upgrade time.

[0006] In a first aspect, the application provides a vehicle controller firmware upgrading method applied to a cloud server, the cloud server being in communication with a vehicle terminal of a target vehicle, the vehicle terminal comprising an upgrading module and a plurality of embedded gateways, the upgrading module being connected to each of the embedded gateways through a single Ethernet communication link, the method comprising: obtaining a parallel flashing matrix, wherein the parallel flashing matrix defines a plurality of parallel flashing nodes, each of the parallel flashing nodes being associated with a group of vehicle controllers to be upgraded, different vehicle controllers corresponding to different communication network segments, each communication network segment belonging to one embedded gateway, and each embedded gateway comprising at least one communication network segment; generating, for each target parallel flashing node in the parallel flashing matrix, a corresponding target parallel upgrading sequence; and sending the target parallel upgrading sequence corresponding to each target parallel flashing node to the upgrading module, wherein the upgrading module is configured to send firmware upgrading data to a plurality of vehicle controllers corresponding to the target parallel flashing node based on the target parallel upgrading sequence, so as to perform parallel firmware flashing on the plurality of vehicle controllers corresponding to the target parallel flashing node.

[0007] In some embodiments, the obtaining of the parallel flashing matrix comprises: obtaining network topology configuration information of the target vehicle; grouping vehicle controllers to be upgraded in the target vehicle based on the network topology configuration information to obtain a plurality of first controller sets; and generating the parallel flashing matrix according to the plurality of first controller sets, wherein each parallel flashing node in the parallel flashing matrix corresponds to one of the first controller sets.

[0008] In some embodiments, the network topology configuration information comprises gateway configuration information and communication network segment information of each vehicle controller; the grouping of vehicle controllers to be upgraded in the target vehicle based on the network topology configuration information to obtain a plurality of first controller sets comprises: screening the vehicle controllers to be upgraded based on the gateway configuration information to obtain a second controller set, wherein the second controller set comprises vehicle controllers connected to the embedded gateways; grouping vehicle controllers in the second controller set based on the communication network segment information to obtain a plurality of controller sub-sets, wherein vehicle controllers in different controller sub-sets belong to different communication network segments; and determining the plurality of first controller sets based on the plurality of controller sub-sets, wherein vehicle controllers in any of the first controller sets satisfy a communication topology condition for parallel flashing.

[0009] In some embodiments, the grouping the vehicle controllers to be upgraded in the target vehicle based on the network topology configuration information to obtain a plurality of first controller sets further comprises: screening the vehicle controllers to be upgraded based on the gateway configuration information to obtain a third controller set, wherein the third controller set comprises vehicle controllers as independent upgrading units; and determining the plurality of first controller sets based on the third controller set and the plurality of controller subsets comprises: determining the plurality of first controller sets based on the third controller set and the plurality of controller subsets.

[0010] In some embodiments, determining the plurality of first controller sets based on the third controller set and the plurality of controller subsets comprises: determining the number of vehicle controllers in each controller subset, determining a maximum number among the numbers as a target number; creating initial sets corresponding to the target number, distributing vehicle controllers in the third controller set to any of the initial controller sets, and distributing vehicle controllers in each of the controller subsets to the plurality of initial controller sets in a preset order to obtain the plurality of first controller sets.

[0011] In some embodiments, generating the parallel flashing matrix according to the plurality of first controller sets comprises: performing parallel feasibility verification on the plurality of first controller sets based on a preset parallel flashing constraint condition, wherein the parallel flashing constraint condition comprises at least one of a network bandwidth constraint, a gateway processing capability constraint, and a controller-to-controller dependency constraint; if the parallel feasibility verification passes, mapping the plurality of first controller sets to corresponding parallel flashing nodes respectively; and arranging the plurality of parallel flashing nodes to form the parallel flashing matrix in a preset node execution order, wherein the preset node execution order is determined based on the upgrading priority of each first controller set and the network topology structure.

[0012] In some embodiments, generating, for each target parallel flashing node in the parallel flashing matrix, a corresponding target parallel upgrading sequence comprises: for each target parallel flashing node in the parallel flashing matrix, obtaining diagnostic logical addresses of a plurality of vehicle controllers corresponding to the target parallel flashing node; generating a parallel flashing instruction set corresponding to the target parallel flashing node based on the diagnostic logical addresses, wherein the parallel flashing instruction set is used to instruct the vehicle terminal to send, under the single Ethernet communication link, flashing control instructions to the plurality of vehicle controllers concurrently with the plurality of diagnostic logical addresses as distinguishing identifiers; and sequentially packaging and integrating whole-vehicle communication mute instructions, the parallel flashing instruction set, and whole-vehicle communication un-mute instructions to obtain the target parallel upgrading sequence corresponding to the target parallel flashing node.

[0013] In some embodiments, the generating the parallel programming instruction set corresponding to the target parallel programming node based on the diagnostic logical address comprises: generating a parallel pre-programming sequence corresponding to the target parallel programming node based on the diagnostic logical address, wherein the parallel pre-programming sequence is used to instruct the vehicle terminal to identify a plurality of diagnostic logical addresses under the single Ethernet communication link, and to issue erase instructions and storage area initialization instructions in parallel to make the firmware storage area of the plurality of vehicle controllers enter a writable state; generating a parallel programming sequence corresponding to the target parallel programming node based on the diagnostic logical address, wherein the parallel programming sequence is used to instruct the vehicle terminal to transmit firmware data packets in a fragmented manner in parallel, and to control data reception, writing and progress synchronization according to each diagnostic logical address respectively; generating a parallel verification sequence corresponding to the target parallel programming node based on the diagnostic logical address, wherein the parallel verification sequence is used to instruct the vehicle terminal to issue verification request instructions in parallel, and to determine the firmware programming success state of the plurality of vehicle controllers according to the verification results or version information returned by the plurality of vehicle controllers; and combining the parallel pre-programming sequence, the parallel programming sequence and the parallel verification sequence in sequence to form the parallel programming instruction set corresponding to the target parallel programming node.

[0014] In some embodiments, the upgrade module is further configured to: create a plurality of parallel execution processes corresponding to the target parallel programming node; divide the firmware upgrade data into a plurality of firmware data fragments; generate a target data frame based on a diagnostic logical address corresponding to each parallel execution process, wherein the target data frame comprises the plurality of firmware data fragments and programming control instructions corresponding to the diagnostic logical address in the target parallel programming sequence; and alternately transmit the target data frames carrying different diagnostic logical addresses to the embedded gateway through the single Ethernet communication link.

[0015] In some embodiments, the alternately transmitting the target data frames carrying different diagnostic logical addresses to the embedded gateway through the single Ethernet communication link comprises: obtaining a first bandwidth of the single Ethernet communication link and a second bandwidth of a communication link between the embedded gateway and a vehicle controller; determining a first data transmission capacity based on the first bandwidth and a second data transmission capacity based on the second bandwidth; and alternately transmitting the target data frames carrying different diagnostic logical addresses to the embedded gateway through the single Ethernet communication link when the first data transmission capacity is greater than or equal to a first preset capacity and the second data transmission capacity is greater than or equal to a second preset capacity.

[0016] In some embodiments, the upgrade module is further configured to: detect a cache usage rate of the embedded gateway during the parallel firmware flashing process; reduce a rate of transmitting the firmware upgrade data to the embedded gateway through the single Ethernet communication link when the cache usage rate is greater than or equal to a preset usage threshold; and increase the rate of transmitting the firmware upgrade data to the embedded gateway through the single Ethernet communication link when the cache usage rate is less than the preset usage threshold.

[0017] In some embodiments, the cloud server comprises an over-the-air technology cloud server and a remote virtual data center cloud server; the obtaining the parallel flashing matrix comprises: obtaining the parallel flashing matrix by the over-the-air technology cloud server; the generating, for each target parallel flashing node in the parallel flashing matrix, a corresponding target parallel upgrade sequence comprises: receiving, by the remote virtual data center cloud server, the parallel flashing matrix sent by the over-the-air technology cloud server, and generating, for each target parallel flashing node in the parallel flashing matrix, a corresponding target parallel upgrade sequence; and the sending, to the upgrade module, the target parallel upgrade sequence corresponding to each target parallel flashing node comprises: sending, by the remote virtual data center cloud server, the target parallel upgrade sequence corresponding to each target parallel flashing node to the upgrade module.

[0018] In a second aspect, the present application also provides a vehicle controller firmware upgrade device applied to a cloud server, the cloud server being in communication with a vehicle terminal of a target vehicle, the vehicle terminal comprising an upgrade module and a plurality of embedded gateways, the upgrade module being connected to each of the embedded gateways through a single Ethernet communication link, and the vehicle controller firmware upgrade device comprising: a matrix obtaining unit configured to obtain a parallel flashing matrix, wherein the parallel flashing matrix defines a plurality of parallel flashing nodes, each of the parallel flashing nodes being associated with a group of vehicle controllers to be upgraded, different vehicle controllers corresponding to different communication network segments, each communication network segment belonging to one embedded gateway, and each embedded gateway comprising at least one communication network segment; a sequence generating unit configured to generate, for each target parallel flashing node in the parallel flashing matrix, a corresponding target parallel upgrade sequence; and a parallel flashing unit configured to send the target parallel upgrade sequence corresponding to each target parallel flashing node to the upgrade module, wherein the upgrade module is configured to send firmware upgrade data to a plurality of vehicle controllers corresponding to the target parallel flashing node concurrently based on the target parallel upgrade sequence, so as to perform parallel firmware flashing on the plurality of vehicle controllers corresponding to the target parallel flashing node.

[0019] Thirdly, this application also provides another method for upgrading the firmware of an on-board controller, applied to a target vehicle. The on-board terminal of the target vehicle includes an upgrade module and an embedded gateway. The upgrade module is connected to the embedded gateway via a single Ethernet communication link. The method includes: receiving a target parallel upgrade sequence issued by a cloud server, wherein the target parallel upgrade sequence is generated by the cloud server based on each target parallel flashing node in a parallel flashing matrix. The parallel flashing matrix defines multiple parallel flashing nodes, each of which is associated with a group of on-board controllers to be upgraded. Different on-board controllers correspond to different communication network segments, each communication network segment belongs to an embedded gateway, and each embedded gateway includes at least one communication network segment; and concurrently sending firmware upgrade data to multiple on-board controllers corresponding to the target parallel flashing nodes through the upgrade module, so as to perform firmware flashing on the multiple on-board controllers corresponding to the target parallel flashing nodes in parallel.

[0020] In some implementations, the step of concurrently sending firmware upgrade data to multiple vehicle controllers corresponding to the target parallel flashing node via the upgrade module includes: creating multiple parallel execution processes corresponding to the target parallel flashing node via the upgrade module; dividing the firmware upgrade data into multiple firmware data fragments; generating a target data frame based on the diagnostic logic address corresponding to each of the parallel execution processes, wherein the target data frame includes the multiple firmware data fragments and a flashing control instruction corresponding to the diagnostic logic address in the target parallel upgrade sequence; alternately transmitting the target data frames carrying different diagnostic logic addresses to the embedded gateway via the single Ethernet communication link; and routing the received target data frames to the corresponding vehicle controller via the embedded gateway based on the diagnostic logic address.

[0021] In some implementations, the step of alternately transmitting target data frames carrying different diagnostic logic addresses to the embedded gateway via the single Ethernet communication link includes: obtaining a first bandwidth of the single Ethernet communication link and a second bandwidth of the communication link between the embedded gateway and the downstream vehicle controller; determining a first data transmission capacity based on the first bandwidth and a second data transmission capacity based on the second bandwidth; and, when the first data transmission capacity is greater than or equal to a first preset capacity and the second data transmission capacity is greater than or equal to a second preset capacity, alternately transmitting target data frames carrying different diagnostic logic addresses to the embedded gateway via the single Ethernet communication link.

[0022] In some embodiments, the vehicle controller firmware upgrade method further includes: during the parallel firmware flashing process, detecting the cache utilization rate of the embedded gateway; if the cache utilization rate is greater than or equal to a preset utilization rate threshold, reducing the rate at which the firmware upgrade data is transmitted to the embedded gateway via the single Ethernet communication link; and if the cache utilization rate is less than the preset utilization rate threshold, increasing the rate at which the firmware upgrade data is transmitted to the embedded gateway via the single Ethernet communication link.

[0023] Fourthly, this application also provides another vehicle controller firmware upgrade device, applied to a cloud server. The cloud server communicates with the vehicle terminal of the target vehicle. The vehicle terminal includes an upgrade module and multiple embedded gateways. The upgrade module is connected to each of the embedded gateways via a single Ethernet communication link. The device includes: a sequence receiving unit for receiving a target parallel upgrade sequence sent by the cloud server, wherein the target parallel upgrade sequence is generated by the cloud server based on each target parallel flashing node in a parallel flashing matrix; the parallel flashing matrix defines multiple parallel flashing nodes, each of which is associated with a group of vehicle controllers to be upgraded. Different vehicle controllers correspond to different communication network segments, each communication network segment belongs to an embedded gateway, and each embedded gateway includes at least one communication network segment; and a flashing execution unit for concurrently sending firmware upgrade data to the multiple vehicle controllers corresponding to the target parallel flashing nodes through the upgrade module, so as to perform parallel firmware flashing on the multiple vehicle controllers corresponding to the target parallel flashing nodes.

[0024] Fifthly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory to implement the steps of the vehicle controller firmware upgrade method described in the first or third aspect.

[0025] Sixthly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the vehicle controller firmware upgrade method described in the first or third aspect.

[0026] Seventhly, this application also provides a computer program product, including a computer program or computer-executable instructions, wherein when the computer program or computer-executable instructions are executed by a processor, the steps of the vehicle controller firmware upgrade method provided in the embodiments of this application are implemented.

[0027] In summary, this application generates a parallel flashing matrix on the cloud server, groups multiple vehicle controllers to be upgraded according to their communication network segments, and forms multiple parallel flashing nodes. Each parallel flashing node corresponds to a group of controllers that can be upgraded simultaneously, enabling orderly parallel upgrades of the entire vehicle controllers and laying the foundation for subsequent efficient flashing. By generating the upgrade plan and scheduling logic on the cloud server, the computational and scheduling pressure on the vehicle terminal side can be reduced, allowing resource-constrained embedded gateways to participate in the upgrade process more efficiently, thereby improving the overall execution stability and reliability of the system. After receiving the parallel upgrade sequence from the cloud, the upgrade module can simultaneously send firmware upgrade data to multiple vehicle controllers according to the sequence, performing parallel flashing of controllers in different communication network segments. This breaks through the limitations of traditional sequential upgrades, improves the concurrency of upgrade tasks, and fully utilizes the bandwidth resources of a single Ethernet communication link, making the firmware data transmission process more efficient. Through the above design, parallel firmware upgrades of multiple controllers in the entire vehicle can be achieved without increasing the burden on vehicle hardware resources, shortening the overall upgrade time of the entire vehicle. In summary, the vehicle controller firmware upgrade method provided in this application generates a parallel flashing matrix and upgrade sequence in the cloud and executes them in parallel by the upgrade module. This achieves efficient parallel firmware upgrades for multiple controllers without increasing vehicle hardware resources, thereby improving upgrade efficiency and shortening the overall vehicle upgrade time. Attached Figure Description

[0028] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A schematic flowchart illustrating a vehicle controller firmware upgrade method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the composition structure of an on-board controller firmware upgrade device provided in an embodiment of this application; Figure 3 A flowchart illustrating another vehicle controller firmware upgrade method provided in this application embodiment; Figure 4 A schematic diagram illustrating the composition of another vehicle controller firmware upgrade device provided in this application embodiment; Figure 5 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0030] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0031] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0032] The vehicle controller firmware upgrade method provided in this application is applied to a cloud server. The cloud server communicates with the vehicle terminal of the target vehicle. The vehicle terminal includes an upgrade module and multiple embedded gateways. The upgrade module is connected to each embedded gateway through a single Ethernet communication link.

[0033] In some examples, the cloud server is used to manage the overall upgrade of the vehicle controller firmware and generate vehicle upgrade-related instructions. The target vehicle is a specific new energy vehicle that requires a vehicle controller firmware upgrade and is the ultimate object of the upgrade operation. The vehicle terminal is a hardware and software integrated system installed inside the target vehicle to receive vehicle upgrade-related instructions from the cloud server and execute firmware upgrade operations. It serves as an intermediary connecting the cloud server and the vehicle controller. The upgrade module is the core module in the vehicle terminal responsible for coordinating and executing the firmware upgrade process. It can receive upgrade sequences issued by the cloud server, control data transmission, and manage parallel upgrade processes. The embedded gateway is an embedded device in the vehicle terminal used to connect different communication network segments and realize data routing and protocol conversion. It supports converting Ethernet data sent by the upgrade module into communication protocol data of the corresponding network segment. The single Ethernet communication link is a single Ethernet communication link established between the upgrade module and each embedded gateway. It is used to transmit firmware upgrade data and control instructions, and the single Ethernet communication link follows the Ethernet Protocol.

[0034] Figure 1 This is a schematic flowchart illustrating a vehicle controller firmware upgrade method provided in an embodiment of this application. For example, see [link to example]. Figure 1 The vehicle controller firmware upgrade method provided in this application embodiment may include the following steps 101 to 103: Step 101: Obtain the parallel brushing matrix.

[0035] The parallel writing matrix defines multiple parallel writing nodes. Each parallel writing node is associated with a group of vehicle controllers to be upgraded. Different vehicle controllers correspond to different communication network segments. Each communication network segment belongs to an embedded gateway. Each embedded gateway can include at least one communication network segment.

[0036] In some examples, the parallel flashing matrix is ​​a data structure generated by a cloud server for planning parallel upgrade strategies for vehicle controllers. It contains multiple parallel flashing nodes, each corresponding to a group of vehicle controllers that can be upgraded simultaneously. A parallel flashing node is the basic unit in the parallel flashing matrix; each node is associated with a group of vehicle controllers to be upgraded, and this group of controllers meets the communication conditions for parallel upgrades, such as belonging to different network segments. The parallel flashing nodes can be determined by grouping the controllers to be upgraded in the target vehicle using the cloud server. For example, the controllers associated with parallel flashing node 1 include the left front door controller, the right rear window controller, and the air conditioning control unit, all belonging to different communication network segments. A communication network segment is a network segment in the vehicle network that uses the same communication protocol and belongs to the embedded gateway. Vehicle controllers within the same communication network segment communicate using the same communication protocol. For example, an embedded gateway may have two controller local area network segments, CAN_Segment1 and CAN_Segment2. CAN_Segment1 includes the motor controller, battery management system, etc., while CAN_Segment2 includes the steering controller, brake controller, etc.

[0037] For example, a cloud server can establish communication with the vehicle's onboard terminal to obtain the vehicle's network topology configuration information. This network topology configuration information includes the embedded gateways, communication network segments, and communication protocols of each onboard controller. For instance, the target vehicle's network topology shows that it contains three embedded gateways: gateway A, gateway B, and gateway C. Gateway A has two CAN network segments connected to it: segment A1 and segment A2. Gateway B has one LIN network segment connected to it: segment B1. Gateway C has one Controller Area Network with Flexible Data-Rate (CAN) protocol connected to it. (FD) Network Segment: Network segment C1, each segment contains multiple vehicle controllers to be upgraded. Based on the above network topology configuration information, the cloud server groups the vehicle controllers to be upgraded: controllers belonging to different communication network segments are grouped into the same group to ensure that controllers within the group can be upgraded in parallel; for example, the motor controller in network segment A1, the lighting controller in network segment B1, and the charging controller in network segment C1 are grouped into one group, corresponding to parallel flashing node 1; the battery management system in network segment A2 and the wiper controller in network segment B1 are grouped into another group, corresponding to parallel flashing node 2. The cloud server integrates these grouping results into a parallel flashing matrix. Each parallel flashing node in the matrix is ​​clearly associated with the corresponding controller to be upgraded, and the controllers within each node belong to different communication network segments, respectively belonging to different embedded gateways or different network segments of the same embedded gateway.

[0038] By implementing step 101, multiple on-board controllers in the vehicle to be upgraded are grouped according to their communication network segments and corresponding embedded gateways, and multiple parallel flashing nodes are defined. This allows for the clarification of the network affiliation and parallel feasibility between controllers before the upgrade, thereby achieving structured management of the upgrade task. With the help of this matrix, upgrade units that can be executed simultaneously can be planned in advance, avoiding communication conflicts and improving the organization and controllability of subsequent parallel flashing, thus providing a foundation for the efficient execution of the upgrade process.

[0039] Step 102: For each target parallel writing node in the parallel writing matrix, generate the corresponding target parallel upgrade sequence.

[0040] In some examples, the target parallel flashing node is a specific parallel flashing node currently awaiting processing within the parallel flashing matrix. It is the concrete object for which the cloud server generates the corresponding upgrade sequence, and the associated set of vehicle controllers must meet the communication topology conditions for parallel flashing. For instance, from a parallel flashing matrix containing four nodes, the node associated with "motor controller (network segment A1), lighting controller (network segment B1), and charging controller (network segment C1)" is first selected as the first target parallel flashing node. The corresponding target parallel upgrade sequence is an ordered set of instructions generated by the cloud server for the target parallel flashing node, used to guide the vehicle terminal in performing parallel flashing operations.

[0041] For example, after determining the target parallel flashing node, the cloud server first obtains the diagnostic logic addresses and corresponding communication protocol information of all vehicle controllers associated with that node. These vehicle controllers may include the motor controller, lighting controller, and charging controller. Based on this information, the cloud server generates a parallel flashing instruction set. First, it constructs a parallel pre-programmed sequence, explicitly using each diagnostic logic address as an identifier, to send memory erasure and initialization instructions to the motor controller, lighting controller, and charging controller in parallel. Then, it generates a parallel flashing sequence, specifying that firmware data packets are transmitted in fragments, with each fragment carrying the logical address of the corresponding controller, ensuring that the upgrade module can distinguish and send concurrently. Finally, it generates a parallel verification sequence, containing instructions to send verification requests to each controller to confirm whether the firmware writing is correct. This ultimately forms the target parallel upgrade sequence corresponding to the target parallel flashing node.

[0042] By implementing step 102, a customized upgrade process design can be carried out according to the network characteristics, communication paths and gateway capabilities of different controller groups. This not only enables parallel scheduling of tasks, but also makes the upgrade sequence, data distribution and verification process more reasonable and orderly. It can effectively reduce the load pressure on the embedded gateway and improve the overall efficiency of upgrade execution while ensuring stability.

[0043] Step 103: Send the target parallel upgrade sequence corresponding to each target parallel write node to the upgrade module.

[0044] The upgrade module is used to send firmware upgrade data concurrently to multiple vehicle controllers corresponding to the target parallel flashing node based on the target parallel upgrade sequence, so as to perform firmware flashing in parallel on multiple vehicle controllers corresponding to the target parallel flashing node.

[0045] In some examples, the cloud server can transmit the generated target parallel upgrade sequence one by one to the upgrade module of the vehicle terminal via vehicle Ethernet or mobile network. The transmission process can ensure data integrity and security through encryption protocols. The cloud server can initiate transmission sequentially according to the preset execution order of the parallel flashing nodes. The upgrade module receives and stores the sequence through a built-in communication interface, such as an Ethernet physical layer interface. The upgrade module can parse the instructions in the target parallel upgrade sequence, create multiple parallel execution processes, distinguished by diagnostic logical addresses, and simultaneously transmit firmware upgrade data to multiple vehicle controllers associated with the sequence. Firmware upgrade data can include firmware data packets and flashing control instructions, etc. Data transmission must be adapted to the communication protocol of the network segment to which each controller belongs. For example, after parsing the "SEQ-001" sequence, the upgrade module creates three parallel processes: process 1 for the motor controller with logical address 0x10, process 2 for the lighting controller with logical address 0x12, and process 3 for the charging controller with logical address 0x15. At the same time, it sends firmware data fragments carrying logical addresses to the corresponding embedded gateways through a single Ethernet link. The gateway converts the data into the corresponding network segment protocol and forwards it to the target controller.

[0046] By implementing step 103, the parallel upgrade sequence corresponding to each target parallel flashing node is sent to the upgrade module of the vehicle terminal. The upgrade module then sends firmware upgrade data to multiple vehicle controllers concurrently based on the sequence. This allows controllers on different network segments to be flashed simultaneously at the same time, which can improve the parallelism of the upgrade task, make full use of communication link bandwidth resources, shorten the total time of vehicle firmware upgrade, and improve vehicle upgrade efficiency and user experience.

[0047] In summary, this embodiment generates a parallel flashing matrix on the cloud server, groups multiple vehicle controllers to be upgraded according to their communication network segments, and forms multiple parallel flashing nodes. Each parallel flashing node corresponds to a group of controllers that can be upgraded simultaneously, enabling orderly parallel upgrades of the entire vehicle controllers and laying the foundation for subsequent efficient flashing. By generating the upgrade plan and scheduling logic on the cloud server, the computational and scheduling pressure on the vehicle terminal side can be reduced, allowing resource-constrained embedded gateways to participate in the upgrade process more efficiently, thereby improving the overall execution stability and reliability of the system. After receiving the parallel upgrade sequence from the cloud, the upgrade module can simultaneously send firmware upgrade data to multiple vehicle controllers according to the sequence, performing parallel flashing of controllers in different communication network segments. This breaks through the limitations of traditional sequential upgrades, improves the concurrency of upgrade tasks, fully utilizes the bandwidth resources of a single Ethernet communication link, and makes the firmware data transmission process more efficient. Through the above design, parallel firmware upgrades of multiple controllers in the entire vehicle can be achieved without increasing the burden on vehicle hardware resources, shortening the overall upgrade time of the entire vehicle. In summary, the vehicle controller firmware upgrade method provided in this application generates a parallel flashing matrix and upgrade sequence in the cloud and executes them in parallel by the upgrade module. This achieves efficient parallel firmware upgrades for multiple controllers without increasing vehicle hardware resources, thereby improving upgrade efficiency and shortening the overall vehicle upgrade time.

[0048] In some embodiments, step 101 may include: obtaining network topology configuration information of the target vehicle; grouping the on-board controllers to be upgraded in the target vehicle based on the network topology configuration information to obtain multiple first controller sets; and generating a parallel writing matrix based on the multiple first controller sets, wherein each parallel writing node in the parallel writing matrix corresponds to a first controller set.

[0049] In some examples, network topology configuration information is a structured data set used to describe the connection relationships, communication protocol types, network segment affiliations, and gateway configurations of various hardware units in the target vehicle's in-vehicle network. It is the core basis for realizing the reasonable grouping of controllers to be upgraded. Network topology configuration information may include the number and identification of embedded gateways, the protocol type of each communication network segment, the communication network segment to which each in-vehicle controller belongs and the associated embedded gateway, the communication bandwidth of each network segment, and other information. Cloud servers can categorize and classify vehicle controllers to be upgraded based on network topology configuration information, adhering to the core principle of parallel upgrades. This principle ensures that vehicle controllers within the same group belong to different communication network segments, avoiding data transmission conflicts within the same network segment and not exceeding the processing capacity of the embedded gateway. For example, if a target vehicle's controllers to be upgraded include a motor controller (network segment 1), a window controller (network segment 2), a steering controller (network segment 3), and a battery management system (network segment 1), the cloud server, based on network topology configuration information, identifies that the motor controller and battery management system belong to the same network segment 1 (not parallel), while the motor controller (network segment 1), window controller (network segment 2), and steering controller (network segment 3) belong to different network segments. Therefore, the cloud server categorizes these three controllers into different network segments. The controllers are divided into two groups: the battery management system is divided into another group, and if there are other controllers to be upgraded in different network segments, they can be further combined with the battery management system. Multiple first controller sets are the sets of vehicle controllers to be upgraded obtained through the above grouping operation, each of which meets the conditions for parallel upgrade. All vehicle controllers in each set can receive upgrade data and perform firmware flashing operations in the same time period, and the upgrade efficiency will not be affected by communication network segment conflicts or gateway overload. For example, based on the above grouping results of the controllers to be upgraded, the cloud server generates two first controller sets: first controller set 1, which includes the motor controller, window controller, and steering controller; and first controller set 2, which includes the battery management system and door lock controller. The cloud server can establish a one-to-one correspondence between multiple sets of first controllers and parallel flashing nodes, and arrange these nodes in a structured manner according to a preset node execution order to form a matrix data structure to guide the subsequent upgrade process, thus forming a parallel flashing matrix. The node execution order can be determined based on the controller function priority, network segment bandwidth, etc. For example, the cloud server assigns parallel flashing node 1 to first controller set 1 (including motor controller and steering controller, which are related to power), and assigns parallel flashing node 2 (identified as NODE-02) to first controller set 2 (including window controller and door lock controller, which are related to vehicle comfort). Since the power system controller has a higher priority, the execution order is determined to be parallel flashing node 1 before parallel flashing node 2. The final generated parallel flashing matrix contains 2 parallel flashing nodes, node 1 corresponds to first controller set 1, and node 2 corresponds to first controller set 2, with node 1 being the first in the execution order.

[0050] Through the implementation of the above embodiments, a parallel flashing matrix is ​​automatically generated based on the network topology configuration information of the vehicle. It can accurately complete grouping and mapping according to the network segment and communication path of each controller, thereby ensuring that the internal communication of each parallel flashing node does not interfere with each other. This process does not require manual intervention and can achieve adaptive upgrade task allocation for different vehicle models and gateway structures. It can improve configuration flexibility and provide structured support for the batch upgrade of large-scale vehicles.

[0051] In some embodiments, the aforementioned network topology configuration information may include gateway configuration information and communication network segment information for each vehicle controller; the aforementioned grouping of the vehicle controllers to be upgraded in the target vehicle based on the network topology configuration information to obtain multiple first controller sets may include: filtering the vehicle controllers to be upgraded based on gateway configuration information to obtain a second controller set, wherein the second controller set includes vehicle controllers connected to an embedded gateway; grouping the vehicle controllers in the second controller set based on communication network segment information to obtain multiple controller subsets, wherein the vehicle controllers in different controller subsets belong to different communication network segments; and determining multiple first controller sets based on the multiple controller subsets, wherein the vehicle controllers in any first controller set satisfy the communication topology conditions for parallel flashing.

[0052] In some examples, the gateway configuration information for each vehicle controller is structured data describing the association between each vehicle controller and the embedded gateway. This includes the unique identifier of the embedded gateway to which the vehicle controller is connected, the connection method (such as direct connection or indirect routing), and the protocol conversion configuration of the embedded gateway for the controller (such as the mapping rules for Ethernet to Controller Area Network (CAN) protocol). For example, the gateway configuration information of a target vehicle shows that the Motor Controller (MC) is associated with embedded gateway 1, the connection method is direct connection, and the protocol conversion rule is "Ethernet frame to CAN FD frame"; the Steering Controller (SC) is associated with embedded gateway 2, the connection method is direct connection, and the protocol conversion rule is "Ethernet frame to Controller Area Network (CAN) frame". The communication network segment information for each vehicle controller is the core data used to define the communication network segment to which each vehicle controller belongs. This includes the unique identifier of the network segment, the communication protocol used by the network segment, the communication bandwidth of the network segment, and the upper limit of the number of controllers within the network segment. For example, the communication network segment information to which a motor controller belongs is: network segment identifier "CAN FD-01", protocol type CAN FD, communication bandwidth 2Mbps, and the upper limit of the number of controllers within the network segment is 8. The communication network segment information to which a window controller belongs is: network segment identifier "LIN-02", protocol type LIN, communication bandwidth 20kbps, and the upper limit of the number of controllers within the network segment is 12.

[0053] The cloud server can use gateway configuration information to eliminate independent controllers that do not require an embedded gateway for upgrade from all vehicle controllers to be upgraded, such as some domain controllers, retaining only controllers that require data transmission through an embedded gateway. A preset filtering algorithm can be run, which identifies the gateway association identifier of the vehicle controller. If the identifier is empty (indicating no associated embedded gateway), it is eliminated; if the identifier is an embedded gateway identifier (indicating upgrade requires that gateway), it is retained. The second controller set is the collection of all vehicle controllers to be upgraded that require an embedded gateway, obtained through the above filtering operation. This is the basic data object for subsequent grouping by network segment. All controllers in the second controller set rely on the embedded gateway to complete the reception and protocol conversion of upgrade data; there are no independent upgrade units that do not require a gateway, ensuring that subsequent grouping and parallel flashing are adapted to the architectural limitations of the embedded gateway.

[0054] The process of grouping vehicle controllers in the second controller set based on communication network segment information involves the cloud server classifying controllers belonging to the same network segment within the second controller set into the same group. The core purpose is to distinguish controllers from different network segments, laying the foundation for subsequent parallel flashing units. Controllers in the second controller set can be clustered according to network segment identifiers, with controllers of the same network segment identifier grouped into the same group and controllers of different network segment identifiers grouped into different groups. A controller subset is a subset of vehicle controllers to be upgraded within the same communication network segment, obtained through the above-mentioned grouping operation by network segment. Each subset corresponds to a unique network segment identifier, and the upgrade data of controllers within a subset must be transmitted through the communication protocol of the same network segment. Each controller subset corresponds to a unique communication network segment, and the gateway, network segment identifier, protocol type, or bandwidth of different subsets are all different, ensuring that there are no network segment conflicts between subsets. The process of determining multiple first controller sets based on multiple controller subsets involves the cloud server selecting at least one controller from each of the multiple controller subsets and combining them to form a new set, namely the first controller set. This ensures that the controllers in each new set belong to different subsets, enabling parallel flashing. The multiple first controller sets are the sets of vehicle controllers to be upgraded that all meet the conditions for parallel flashing, obtained through the above combination operation. They are the direct basis for generating the parallel flashing matrix. The vehicle controllers in any first controller set must meet the communication topology conditions for parallel flashing. This means that the controllers in each first controller set must simultaneously meet three conditions: first, they belong to different communication network segments with no data conflicts within the network segments; second, the associated embedded gateway has sufficient processing capacity, such as sufficient Ethernet port bandwidth and protocol conversion rate; and third, there is no flashing dependency between controllers, so there is no need to wait for one controller to complete flashing before starting another controller.

[0055] By implementing the above embodiments, the gateway configuration information and communication network segment information of each vehicle controller are used to accurately group the controllers, ensuring that the controllers in the parallel writing nodes are all in a topology that allows parallel communication. This avoids interference and conflicts between different communication network segments. In the complex multi-bus fusion environment of new energy vehicles, it can improve the orderliness and security of upgrade communication, prevent data packet loss or communication blockage, and ensure the stability and consistency of the parallel upgrade process.

[0056] In some embodiments, the aforementioned grouping of the on-board controllers to be upgraded in the target vehicle based on network topology configuration information to obtain multiple first controller sets may further include: filtering the on-board controllers to be upgraded based on gateway configuration information to obtain a third controller set, wherein the third controller set includes on-board controllers as independent upgrade units; the aforementioned determination of multiple first controller sets based on multiple controller subsets may include: determining multiple first controller sets based on the third controller set and multiple controller subsets.

[0057] In some examples, the cloud server can use the gateway configuration information of each vehicle controller as a basis to separate controllers that can be upgraded without relying on an embedded gateway from all vehicle controllers to be upgraded, forming a complementary filtering logic with the filtering of controllers that need to be upgraded through an embedded gateway; it can identify the gateway association identifier of the vehicle controller, and if the identifier is empty (indicating that the controller has no associated embedded gateway), it is determined to be a controller that can be upgraded independently and retained; the third controller set is the set of vehicle controllers that can be upgraded independently without relying on an embedded gateway, obtained through the above complementary filtering operation. These controllers have built-in Ethernet communication modules and independent firmware storage areas, and have the ability to establish Ethernet communication directly with the upgrade module without going through the protocol conversion or data routing of the embedded gateway. They are usually domain controllers or central computing units with high computing power. This embodiment adds an extended set after the third controller set to the original first controller set generated based on the controller subset. At least one first controller set contains both independent upgrade units from the third controller set and controllers from different controller subsets, and all members meet the conditions for parallel flashing. The process of determining multiple first controller sets based on the third controller set and multiple controller subsets involves the cloud server reasonably combining independent upgrade units (third controller set) with controllers that need to be upgraded by relying on the gateway (multiple controller subsets) to form a first controller set that simultaneously contains two types of controllers and meets the conditions for parallel writing. The core is to achieve collaborative parallelism between independent upgrade units and gateway-associated controllers.

[0058] By implementing the above embodiments, an independent upgrade unit screening mechanism is introduced in the grouping stage. Some controllers with independent communication channels or special functions are separately assigned to the third controller set. This can avoid link conflicts caused by unbalanced grouping and achieve flexible parallel scheduling in the complex architecture where multiple types of controllers coexist. This improves the accuracy and versatility of the parallel grouping strategy and enhances the method's adaptability to different vehicle architectures.

[0059] In some embodiments, the aforementioned determination of multiple first controller sets based on a third controller set and multiple controller subsets may include: determining the number of vehicle controllers in each controller subset, determining the maximum number among the various numbers as the target number; creating an initial set corresponding to the target number, assigning the vehicle controllers in the third controller set to any initial controller set, and sequentially assigning the vehicle controllers in each controller subset to multiple initial controller sets in a preset order to obtain multiple first controller sets.

[0060] In some examples, determining the number of vehicle controllers in each controller subset involves the cloud server counting members in each of the multiple pre-defined controller subsets, calculating the specific number of vehicle controllers to be upgraded within each subset, and providing a quantitative basis for determining the number of initial sets. Determining the maximum number among these as the target number involves the cloud server selecting the largest number from the controller counts of each controller subset and defining it as the target number. The target number directly determines the number of initial sets created subsequently. The initial set is an empty set created by the cloud server based on the target number, used to temporarily host controllers to be assigned. It serves as a transitional carrier for generating the first controller set. Each initial set has a unique identifier and initially contains no controller members. All members can be selected from the third controller set and assigned to any initial set. Then, for each controller subset, its members are sequentially assigned to different initial sets according to a preset order (such as controller function priority or subset identifier order). After allocation, each initial set automatically transforms into the first controller set.

[0061] By implementing the above embodiments, the number of controller subsets is calculated and dynamically allocated according to the maximum set size, thus realizing load balancing of controllers among parallel writing nodes. This can prevent a node from becoming a communication bottleneck due to too many controllers, improve the execution balance and overall upgrade efficiency of the parallel writing matrix, and optimize the bandwidth and resource utilization of the multi-node parallel writing process.

[0062] In some embodiments, the aforementioned generation of a parallel writing matrix based on a plurality of first controller sets may include: performing a parallel feasibility check on the plurality of first controller sets based on preset parallel writing constraints, wherein the parallel writing constraints may include at least one of network bandwidth constraints, gateway processing capacity constraints, and inter-controller dependency constraints; if the parallel feasibility check passes, mapping the plurality of first controller sets to corresponding parallel writing nodes; and arranging the plurality of parallel writing nodes to form a parallel writing matrix according to a preset node execution order, wherein the preset node execution order is determined based on the upgrade priority and network topology of each first controller set.

[0063] In some examples, the preset parallel flashing constraints are a set of rules pre-configured on the cloud server before the vehicle controller firmware upgrade process begins. These rules are based on the target vehicle's hardware architecture (such as embedded gateway specifications and communication link type), network performance, and controller functional association logic. The purpose is to determine whether the first set of controllers is feasible for parallel flashing. This avoids the risks of network congestion, gateway overload, or controller flashing conflicts during parallel upgrades. Network bandwidth constraints are rules within the preset parallel flashing constraints that limit the bandwidth usage of vehicle communication links (including the Ethernet link between the upgrade module and the embedded gateway, and the network segment link between the embedded gateway and the controller). This ensures that when transmitting firmware upgrade data in parallel, the link bandwidth will not exceed its carrying capacity, leading to data loss or delay. For example, if the Ethernet link between the upgrade module and embedded gateway 1 is 100Mbps, the network bandwidth constraint is set to "the upgrade data transmission bandwidth of this Ethernet link shall not exceed 80Mbps"; if the CAN FD network segment bandwidth between embedded gateway 1 and the downstream vehicle controller is 2Mbps, the constraint is set to "the upgrade data transmission bandwidth of this CAN FD network segment shall not exceed 1.6Mbps". Gateway processing capacity constraints are preset parallel flashing constraints that set an upper limit on the embedded gateway's data processing capabilities (including protocol conversion rate and concurrent data forwarding volume). This prevents the gateway from failing to forward data or crashing due to excessive processing pressure during parallel upgrades. For example, if the hardware specifications of embedded gateway 2 show "maximum CAN to Ethernet protocol conversion rate of 1Mbps, maximum number of concurrent forwarding controllers of 8", then the gateway processing capacity constraint can be set to "protocol conversion rate not exceeding 700kbps, number of concurrent forwarding controllers not exceeding 5". Controller dependency constraints are preset parallel flashing constraints that set the flashing order for functionally related vehicle controllers. This ensures that controllers that need to be flashed first (such as dependent controllers) are not flashed simultaneously with the controllers they depend on, avoiding upgrade failures due to functional asynchrony. For example, if the battery management system needs to adjust parameters based on the new firmware version of the motor controller, then the controller dependency constraint is set to "the battery management system and the motor controller cannot be flashed simultaneously; the motor controller must be flashed first".The parallel feasibility verification process involves the cloud server calling preset parallel write constraints to verify the parallel write feasibility of each first controller set one by one. The core is to check whether the parallel upgrade of controllers within the set meets the constraints of network bandwidth, gateway processing capacity, and controller dependencies. In implementation, the first step is to simulate and calculate the link bandwidth occupancy rate during parallel upgrades of controllers within the set to determine if it meets network bandwidth constraints. The second step is to calculate the amount of data that the embedded gateway needs to process for each controller within the set to determine if it meets gateway processing capacity constraints. The third step is to check for dependencies between controllers within the set to determine if they meet inter-controller dependency constraints. If all three steps are satisfied, the verification passes; otherwise, the set members need to be adjusted. Once all first controller sets have passed the parallel feasibility verification, the cloud server can assign a unique parallel write node identifier to each first controller set, establishing a one-to-one correspondence between the first controller sets and the parallel write nodes. This allows the vehicle controller upgrade tasks within the first controller sets to be visualized as node-level tasks for management. The preset node execution order is the sequential execution order set by the cloud server for multiple parallel flashing nodes. This ensures that high-priority or dependent nodes are started for upgrades first, optimizing the efficiency and safety of the entire vehicle upgrade. The execution order can be generated using a sequential sorting algorithm based on preset priority rules (such as controller function priority) and network topology (such as embedded gateway load balancing requirements). For example, a new energy vehicle manufacturer might prioritize powertrain controllers > intelligent cockpit controllers > body comfort controllers, and the network topology might require nodes associated with the same embedded gateway to execute at off-peak times; in this case, the node execution order is determined accordingly. The process of arranging multiple parallel flashing nodes into a parallel flashing matrix according to the preset node execution order involves the cloud server structuring the mapped parallel flashing nodes according to the preset node execution order, forming a matrix data structure containing node identifiers, corresponding controller lists, and execution order. This provides a clear task framework for subsequent upgrade sequence generation and distribution.

[0064] By implementing the above embodiments, performing parallel feasibility verification based on bandwidth, processing power, and dependencies before generating the parallel writing matrix can identify non-parallel tasks in advance and optimize the node arrangement order, thereby avoiding execution failures caused by resource conflicts or upgrade dependencies. In the complex dependency network of multiple ECUs in new energy vehicles, it can ensure the safety and executability of the parallel upgrade plan and improve the stable operation capability of the method.

[0065] In some embodiments, step 102 may include: for each target parallel flashing node in the parallel flashing matrix, obtaining the diagnostic logic addresses of multiple vehicle controllers corresponding to the target parallel flashing node; generating a parallel flashing instruction set corresponding to the target parallel flashing node based on the diagnostic logic addresses, wherein the parallel flashing instruction set is used to instruct the vehicle terminal to send flashing control commands concurrently to multiple vehicle controllers under a single Ethernet communication link, using multiple diagnostic logic addresses as distinguishing identifiers; and sequentially encapsulating and integrating the vehicle communication mute command, the parallel flashing instruction set, and the vehicle communication unmute command to obtain the target parallel upgrade sequence corresponding to the target parallel flashing node.

[0066] In some examples, the diagnostic logic addresses of the multiple vehicle controllers corresponding to the target parallel flashing node are unique logical identifiers used for identification of each vehicle controller associated with the target parallel flashing node in the vehicle diagnostic network. These can be represented by hexadecimal values ​​and are the core basis for establishing the association between the flashing control command and the target controller. The corresponding diagnostic logic address can be retrieved based on the hardware identifier (such as part number) of the vehicle controller; or the diagnostic logic address can be obtained by extracting the pre-stored address mapping relationship from the network topology configuration information. For example, the diagnostic logic address of the motor controller associated with the target parallel flashing node 1 is 0x10, the window controller is 0x12, and the smart cockpit domain controller is 0x20. The parallel flashing instruction set corresponding to the target parallel flashing node is a collection of multiple sub-instructions generated by the cloud server for the target parallel flashing node. These sub-instructions can be functionally categorized into pre-programmed instructions, data transmission instructions, and verification instructions. Each sub-instruction carries a corresponding diagnostic logic address for precise target controller location. The core function of the parallel flashing instruction set is to instruct the vehicle terminal's upgrade module to differentiate the flashing control instructions in the parallel flashing instruction set according to their diagnostic logic addresses and send them simultaneously to multiple vehicle controllers via a single Ethernet communication link. The vehicle communication mute instruction is a control instruction generated by the cloud server before initiating parallel flashing to suspend non-upgrade-related communications of the target vehicle. Its purpose is to prevent other communication data (such as vehicle status messages) from consuming network bandwidth or interfering with upgrade instruction transmission. The vehicle communication unmute instruction is a control instruction generated by the cloud server after parallel flashing is completed and verification passes, used to restore non-upgrade-related communications of the target vehicle, allowing the vehicle network to return to normal operation. The target parallel upgrade sequence corresponding to the target parallel flashing node is an ordered instruction sequence formed by the cloud server after encapsulating and integrating the vehicle communication mute instruction, parallel flashing instruction set, and vehicle communication unmute instruction in the execution order. It is a complete operation instruction sequence that guides the vehicle terminal to complete the parallel flashing of all controllers under this node.

[0067] Through the implementation of the above embodiments, a corresponding parallel upgrade sequence is generated for each parallel flashing node, and the mute, flashing and unmute instructions are uniformly encapsulated in the sequence. This enables the upgrade module to precisely control the communication state and concurrent logic during execution, avoid communication interference or data competition, and achieve a combination of unified scheduling in the cloud and parallel execution on the terminal, thereby improving the synchronization of firmware distribution and the fineness of flashing control.

[0068] In some embodiments, the aforementioned generation of a parallel flashing instruction set corresponding to the target parallel flashing node based on the diagnostic logical address may include: generating a parallel pre-programming sequence corresponding to the target parallel flashing node based on the diagnostic logical address, wherein the parallel pre-programming sequence is used to instruct the vehicle terminal to send erase instructions and storage area initialization instructions in parallel under a single Ethernet communication link, using multiple diagnostic logical addresses as target identifiers, so that the firmware storage areas of multiple vehicle controllers enter a writable state; generating a parallel flashing sequence corresponding to the target parallel flashing node based on the diagnostic logical address, wherein the parallel flashing sequence is used to instruct the vehicle terminal to transmit firmware data packets in parallel in a fragmented manner, and control data reception, writing, and progress synchronization according to each diagnostic logical address; generating a parallel verification sequence corresponding to the target parallel flashing node based on the diagnostic logical address, wherein the parallel verification sequence is used to instruct the vehicle terminal to send verification request instructions in parallel, and determine the firmware flashing success status of multiple vehicle controllers according to the verification results or version information returned by multiple vehicle controllers; and combining the parallel pre-programming sequence, parallel flashing sequence, and parallel verification sequence in sequence to form a parallel flashing instruction set corresponding to the target parallel flashing node.

[0069] In some examples, the parallel pre-programming sequence corresponding to the target parallel flashing node is a sequence of instructions generated by the cloud server for the target parallel flashing node to start the preprocessing of the firmware storage area. It includes erase instructions (used to clear the old firmware) and storage area initialization instructions (used to configure storage area parameters, such as partition size and read / write permissions). Each instruction carries a corresponding diagnostic logic address to locate the target controller. The core function of the parallel pre-programming sequence is to instruct the upgrade module of the vehicle terminal to send the instructions in the parallel pre-programming sequence according to the diagnostic logic address through a single Ethernet communication link to multiple vehicle controllers at the same time, so that the firmware storage area of ​​each controller is changed from a read-only or old data storage state to a state where new firmware can be written.

[0070] The parallel flashing sequence corresponding to the target parallel flashing node is a sequence of instructions generated by the cloud server for transmitting new firmware data. It divides the firmware file into fragments of a fixed size (e.g., 128 bytes), each fragment carrying the diagnostic logic address of the corresponding vehicle controller, and all fragments are arranged in parallel transmission logic to ensure that multiple vehicle controllers can receive data simultaneously. The core function of the parallel flashing sequence is to instruct the upgrade module of the vehicle terminal to divide the firmware data into fragments and transmit them to multiple controllers simultaneously through a single Ethernet link, and to independently control data reception confirmation, storage writing, and progress feedback for each vehicle controller.

[0071] The parallel verification sequence corresponding to the target parallel flashing node is a sequence of instructions generated by the cloud server for the target parallel flashing node to confirm the validity of firmware flashing. It includes verification request instructions (used to obtain the new firmware verification value or version number stored in the controller) and result judgment logic. Each instruction carries the corresponding diagnostic logic address. The core function of the parallel verification sequence is to guide the vehicle terminal upgrade module to send verification requests to multiple controllers at the same time. By comparing the returned verification value with the expected value, or checking whether the version number is consistent with the target version, it determines whether the flashing of each controller is successful.

[0072] The cloud server can combine the above three sequences into a complete instruction set in a fixed order of parallel pre-programming sequence, parallel writing sequence, and parallel verification sequence, ensuring that the vehicle terminal completes the entire process from storage preprocessing to data transmission and then to validity verification.

[0073] By implementing the above embodiments, the parallel flashing instruction set is subdivided into pre-programming sequence, flashing sequence and verification sequence, which can achieve precise control and real-time verification at different stages of firmware upgrade. In the multi-controller collaborative environment of new energy vehicles, it can effectively prevent version inconsistency problems caused by erase or write anomalies of some controllers, and improve the consistency and reliability of vehicle firmware upgrade.

[0074] In some embodiments, the cloud server may include a server cluster deployed in the cloud. In the firmware upgrade scenario of new energy vehicles, the server cluster may include an Over-the-Air Technology Cloud Server (OTA Cloud Server) and a Remote Virtual Data Center Cloud Server (RVDC Cloud Server). Different cloud servers work together to complete the upgrade-related data processing and instruction distribution. Step 101 may include: obtaining a parallel flashing matrix through the OTA Cloud Server; Step 102 may include: receiving the parallel flashing matrix sent by the OTA Cloud Server through the Remote Virtual Data Center Cloud Server, and generating a corresponding target parallel upgrade sequence for each target parallel flashing node in the parallel flashing matrix; Step 103 may include: sending the target parallel upgrade sequence corresponding to each target parallel flashing node to the upgrade module through the Remote Virtual Data Center Cloud Server.

[0075] In some examples, the over-the-air (OTA) cloud server is a cloud service node specifically responsible for real-time interaction with the target vehicle, collecting vehicle status information (such as a list of onboard controllers to be upgraded and network topology configuration), and generating preliminary upgrade plans (such as parallel write matrix). Its core function is to realize basic data interaction between the vehicle and the cloud and preliminary scheduling of upgrade tasks. The OTA cloud server can be a dedicated server cluster built on a public cloud platform, establishing an encrypted communication link with the vehicle's upgrade module through a 5G network. The steps in step 101 mentioned above can be executed by the OTA cloud server. The remote virtual data center cloud server is a high-performance cloud service node deployed in the vehicle manufacturer's private virtual data center, responsible for handling complex upgrade logic (such as generating target parallel upgrade sequences). Its core function is to generate an executable upgrade sequence containing specific instructions based on the initial planning provided by the over-the-air (OTA) cloud server, and to ensure the security and compatibility of the sequence. The remote virtual data center cloud server can be a server cluster built in a private data center based on virtualization technology, with high computing power and data isolation capabilities. It mainly interacts with the OTA cloud server and the vehicle's upgrade module. The steps 102 to 103 mentioned above can be executed by the remote virtual data center cloud server.

[0076] Through the implementation of the above embodiments, the cloud server for over-the-air download technology and the cloud server for remote virtual data center are distinguished in the cloud architecture, realizing the layered collaboration of firmware distribution and scheduling computation. This can effectively reduce the load on a single server and improve task processing efficiency. It not only meets the needs of the group upgrade of new energy vehicles, but also enables high-concurrency, large-scale, and low-latency firmware upgrade management in the remote maintenance system of car companies, thereby enhancing the scalability and service capabilities of the method.

[0077] In some embodiments, the aforementioned upgrade module is further configured to: create multiple parallel execution processes corresponding to the target parallel flashing node; divide the firmware upgrade data into multiple firmware data fragments; generate a target data frame based on the diagnostic logic address corresponding to each parallel execution process, wherein the target data frame may include multiple firmware data fragments and flashing control instructions corresponding to the diagnostic logic address in the target parallel upgrade sequence; alternately transmit target data frames carrying different diagnostic logic addresses to the embedded gateway through a single Ethernet communication link; and route the received target data frames to the corresponding vehicle controller through the embedded gateway based on the diagnostic logic address.

[0078] By implementing the above embodiments, multiple parallel execution processes are created in the upgrade module, and firmware data is fragmented and encapsulated using diagnostic logical addresses as distinguishing identifiers. This enables independent communication and concurrent control of different controllers, thereby improving the bandwidth utilization of a single Ethernet communication link. It also allows the embedded gateway to automatically route target data frames based on diagnostic addresses, avoiding communication conflicts and link congestion, and ensuring the orderliness and real-time performance of data transmission. Compared to traditional serial upgrade methods, it can achieve process-level parallelism and data-level distribution parallelism, and can improve firmware distribution speed and the ability to simultaneously flash multiple controllers.

[0079] In some embodiments, the aforementioned method of alternately transmitting target data frames carrying different diagnostic logic addresses to the embedded gateway via a single Ethernet communication link may include: obtaining a first bandwidth of the single Ethernet communication link and a second bandwidth of the communication link between the embedded gateway and the downstream vehicle controller; determining a first data transmission capacity based on the first bandwidth and a second data transmission capacity based on the second bandwidth; and, when the first data transmission capacity is greater than or equal to a first preset capacity and the second data transmission capacity is greater than or equal to a second preset capacity, alternately transmitting target data frames carrying different diagnostic logic addresses to the embedded gateway via the single Ethernet communication link.

[0080] Through the implementation of the above embodiments, the bandwidth capacity of the single Ethernet communication link and the gateway-connected link is dynamically monitored, and the data transmission conditions are judged based on the real-time transmission capabilities of different communication channels. Under the premise that system resources allow, the data frames can be transmitted alternately in parallel, thereby realizing link-level load balancing and bandwidth adaptive scheduling. This can effectively avoid data blocking or packet loss caused by network bottlenecks or communication rate mismatch, and ensure the communication stability and data integrity of multiple vehicle controllers during the parallel flashing process. This makes the upgrade process more efficient and reliable, and is particularly suitable for the complex multi-segment communication architecture in new energy vehicles.

[0081] In some embodiments, the upgrade module is further configured to: detect the cache utilization rate of the embedded gateway during the parallel firmware flashing process; reduce the rate of transmitting firmware upgrade data to the embedded gateway via a single Ethernet communication link when the cache utilization rate is greater than or equal to a preset utilization rate threshold; and increase the rate of transmitting firmware upgrade data to the embedded gateway via a single Ethernet communication link when the cache utilization rate is less than the preset utilization rate threshold.

[0082] By implementing the above embodiments, the cache utilization rate of the embedded gateway is detected in real time during the parallel flashing process, and the data transmission rate is dynamically adjusted based on it. This enables adaptive control of the transmission load, thereby preventing cache overflow, data accumulation, or communication delays. It can effectively balance the relationship between the cloud data delivery rate and the gateway processing capacity, ensuring the continuity and stability of parallel upgrade tasks. In the resource-constrained embedded gateway architecture of new energy vehicles, it can not only improve the vehicle system's anti-congestion capability but also enhance the reliability and security of data transmission during the vehicle upgrade process.

[0083] Furthermore, as an implementation of the aforementioned method embodiments, this application also provides an on-board controller firmware upgrade device for implementing the aforementioned method embodiments. This device embodiment corresponds to the aforementioned method embodiments. For ease of reading, this on-board controller firmware upgrade device embodiment will not repeat the details of the aforementioned method embodiments one by one, but it should be understood that the device in this application embodiment can correspondingly implement all the contents of the aforementioned method embodiments. For example... Figure 2As shown, the vehicle controller firmware upgrade device 20 includes: a matrix acquisition unit 201, a sequence generation unit 202, and a parallel flashing unit 203. The matrix acquisition unit 201 acquires a parallel flashing matrix, which defines multiple parallel flashing nodes. Each parallel flashing node is associated with a group of vehicle controllers to be upgraded. Different vehicle controllers correspond to different communication network segments, and each communication network segment belongs to an embedded gateway. Each embedded gateway may include at least one communication network segment. The sequence generation unit 202 generates a corresponding target parallel upgrade sequence for each target parallel flashing node in the parallel flashing matrix. The parallel flashing unit 203 sends the target parallel upgrade sequence corresponding to each target parallel flashing node to the upgrade module. The upgrade module concurrently sends firmware upgrade data to multiple vehicle controllers corresponding to the target parallel flashing node based on the target parallel upgrade sequence, thereby performing parallel firmware flashing on the multiple vehicle controllers corresponding to the target parallel flashing node.

[0084] In some embodiments, the matrix acquisition unit 201 is further configured to acquire network topology configuration information of the target vehicle; based on the network topology configuration information, group the on-board controllers to be upgraded in the target vehicle to obtain multiple first controller sets; and generate a parallel writing matrix according to the multiple first controller sets, wherein each parallel writing node in the parallel writing matrix corresponds to a first controller set.

[0085] In some embodiments, the network topology configuration information includes gateway configuration information and communication network segment information for each vehicle controller; the matrix acquisition unit 201 is further configured to filter the vehicle controllers to be upgraded based on the gateway configuration information to obtain a second controller set, wherein the second controller set includes vehicle controllers connected to the embedded gateway; based on the communication network segment information, the vehicle controllers in the second controller set are grouped to obtain multiple controller subsets, wherein the vehicle controllers in different controller subsets belong to different communication network segments; based on the multiple controller subsets, multiple first controller sets are determined, wherein the vehicle controllers in any first controller set satisfy the communication topology conditions for parallel writing.

[0086] In some embodiments, the matrix acquisition unit 201 is further configured to filter the vehicle controllers to be upgraded based on gateway configuration information to obtain a third controller set, wherein the third controller set includes vehicle controllers as independent upgrade units; and to determine a plurality of first controller sets based on a plurality of controller subsets, including: determining a plurality of first controller sets based on the third controller set and the plurality of controller subsets.

[0087] In some embodiments, the matrix acquisition unit 201 is further configured to determine the number of vehicle controllers in each controller subset, determine the maximum number among the various numbers as the target number; create an initial set corresponding to the target number, assign the vehicle controllers in the third controller set to any initial controller set, and assign the vehicle controllers in each controller subset to multiple initial controller sets in a preset order to obtain multiple first controller sets.

[0088] In some embodiments, the matrix acquisition unit 201 is further configured to perform parallel feasibility verification on multiple first controller sets based on preset parallel writing constraints, wherein the parallel writing constraints include at least one of network bandwidth constraints, gateway processing capacity constraints, and inter-controller dependency constraints; if the parallel feasibility verification passes, the multiple first controller sets are mapped to corresponding parallel writing nodes respectively; and the multiple parallel writing nodes are arranged to form a parallel writing matrix according to a preset node execution order, wherein the preset node execution order is determined based on the upgrade priority and network topology of each first controller set.

[0089] In some embodiments, the sequence generation unit 202 is further configured to, for each target parallel flashing node in the parallel flashing matrix, obtain the diagnostic logic addresses of multiple vehicle controllers corresponding to the target parallel flashing node; based on the diagnostic logic addresses, generate a parallel flashing instruction set corresponding to the target parallel flashing node, wherein the parallel flashing instruction set is used to instruct the vehicle terminal to send flashing control instructions concurrently to multiple vehicle controllers under a single Ethernet communication link, using multiple diagnostic logic addresses as distinguishing identifiers; and sequentially encapsulate and integrate the vehicle communication mute instruction, the parallel flashing instruction set, and the vehicle communication unmute instruction to obtain the target parallel upgrade sequence corresponding to the target parallel flashing node.

[0090] In some embodiments, the parallel flashing unit 203 is further configured to generate a parallel pre-programming sequence corresponding to the target parallel flashing node based on the diagnostic logical address, wherein the parallel pre-programming sequence is used to instruct the vehicle terminal to send erase instructions and storage area initialization instructions in parallel under a single Ethernet communication link, using multiple diagnostic logical addresses as target identifiers, so that the firmware storage areas of multiple vehicle controllers enter a writable state; generate a parallel flashing sequence corresponding to the target parallel flashing node based on the diagnostic logical address, wherein the parallel flashing sequence is used to instruct the vehicle terminal to transmit firmware data packets in parallel in a fragmented manner, and control data reception, writing and progress synchronization according to each diagnostic logical address; generate a parallel verification sequence corresponding to the target parallel flashing node based on the diagnostic logical address, wherein the parallel verification sequence is used to instruct the vehicle terminal to send verification request instructions in parallel, and determine the firmware flashing success status of multiple vehicle controllers according to the verification results or version information returned by multiple vehicle controllers; and combine the parallel pre-programming sequence, parallel flashing sequence and parallel verification sequence in sequence to form a parallel flashing instruction set corresponding to the target parallel flashing node.

[0091] In some embodiments, the upgrade module is further configured to: create multiple parallel execution processes corresponding to the target parallel flashing node; divide the firmware upgrade data into multiple firmware data fragments; generate a target data frame based on the diagnostic logic address corresponding to each parallel execution process, wherein the target data frame includes multiple firmware data fragments and flashing control instructions corresponding to the diagnostic logic address in the target parallel upgrade sequence; alternately transmit target data frames carrying different diagnostic logic addresses to the embedded gateway through a single Ethernet communication link; and route the received target data frames to the corresponding vehicle controller through the embedded gateway based on the diagnostic logic address.

[0092] In some embodiments, the upgrade module is further configured to: obtain a first bandwidth of a single Ethernet communication link and a second bandwidth of a communication link between the embedded gateway and the under-mount vehicle controller; determine a first data transmission capacity based on the first bandwidth and a second data transmission capacity based on the second bandwidth; and, when the first data transmission capacity is greater than or equal to a first preset capacity and the second data transmission capacity is greater than or equal to a second preset capacity, alternately transmit target data frames carrying different diagnostic logic addresses to the embedded gateway through the single Ethernet communication link.

[0093] In some embodiments, the upgrade module is further configured to: detect the cache utilization rate of the embedded gateway during the parallel firmware flashing process; reduce the rate of transmitting firmware upgrade data to the embedded gateway via a single Ethernet communication link when the cache utilization rate is greater than or equal to a preset utilization rate threshold; and increase the rate of transmitting firmware upgrade data to the embedded gateway via a single Ethernet communication link when the cache utilization rate is less than the preset utilization rate threshold.

[0094] In some embodiments, the cloud server includes an over-the-air (OTA) cloud server and a remote virtual data center (VRDC) cloud server; the matrix acquisition unit 201 is further configured to acquire a parallel brushing matrix via the OTA cloud server; the sequence generation unit 202 is further configured to receive the parallel brushing matrix sent by the OTA cloud server via the VRDC cloud server, and generate a corresponding target parallel upgrade sequence for each target parallel brushing node in the parallel brushing matrix; the parallel brushing unit 203 is further configured to send the target parallel upgrade sequence corresponding to each target parallel brushing node to the upgrade module via the VRDC cloud server.

[0095] Another vehicle controller firmware upgrade method provided in this application embodiment is applied to a target vehicle. The vehicle terminal of the target vehicle includes an upgrade module and an embedded gateway. The upgrade module and the embedded gateway are connected through a single Ethernet communication link. Figure 3 This is a schematic flowchart illustrating another vehicle controller firmware upgrade method provided in this application embodiment. For example, see [link to example]. Figure 3 The vehicle controller firmware upgrade method provided in this application embodiment may include the following steps 301 to 302: Step 301: Receive the target parallel upgrade sequence issued by the cloud server. The target parallel upgrade sequence is generated by the cloud server based on each target parallel writing node in the parallel writing matrix. The aforementioned parallel writing matrix defines multiple parallel writing nodes. Each parallel writing node is associated with a group of vehicle controllers to be upgraded. Different vehicle controllers correspond to different communication network segments. Each communication network segment belongs to an embedded gateway. Each embedded gateway may include at least one communication network segment. Step 302: The firmware upgrade data is sent concurrently to multiple vehicle controllers corresponding to the target parallel flashing node through the upgrade module, so as to perform firmware flashing in parallel on multiple vehicle controllers corresponding to the target parallel flashing node. In summary, this application embodiment, by using a target parallel upgrade sequence issued by a cloud server on the vehicle terminal side and employing an upgrade module to concurrently send firmware upgrade data to multiple vehicle controllers, enables efficient parallel firmware flashing in the multi-controller, distributed network architecture of new energy vehicles. This overcomes the limitations of traditional sequential upgrade modes on bandwidth and processing capabilities, allowing multiple controllers to simultaneously transmit and write firmware, significantly improving the execution efficiency of the vehicle upgrade and shortening vehicle downtime. Furthermore, since the parallel relationships between controllers are uniformly planned in the cloud, optimal resource allocation can be achieved without increasing the computational burden on the gateway, thereby improving upgrade reliability and resource utilization.

[0096] In some embodiments, the aforementioned concurrent transmission of firmware upgrade data to multiple vehicle controllers corresponding to the target parallel flashing node via the upgrade module may include: creating multiple parallel execution processes corresponding to the target parallel flashing node via the upgrade module; dividing the firmware upgrade data into multiple firmware data fragments; generating a target data frame based on the diagnostic logic address corresponding to each parallel execution process, wherein the target data frame may include multiple firmware data fragments and flashing control instructions corresponding to the diagnostic logic address in the target parallel upgrade sequence; alternately transmitting target data frames carrying different diagnostic logic addresses to the embedded gateway via a single Ethernet communication link; and routing the received target data frames to the corresponding vehicle controller via the embedded gateway based on the diagnostic logic address.

[0097] In some examples, the multiple parallel execution processes corresponding to the target parallel flashing node are independent execution units created by the upgrade module for each vehicle controller associated with the target parallel flashing node. These processes are used to concurrently handle the fragmented transmission of firmware upgrade data, command sending, and progress feedback. Each process corresponds to a unique vehicle controller (bound via a diagnostic logic address). The upgrade module's process management unit (MMU) generates an equal number of processes based on the number of vehicle controllers associated with the target parallel flashing node by calling a process creation interface (such as the POSIX fork function), and assigns a corresponding diagnostic logic address as an identifier to each process. For example, if the target parallel flashing node is associated with a motor controller (MC, diagnostic logic address 0x10), a window controller (WC, 0x12), and a smart cockpit domain controller (SCDC, 0x20), the upgrade module creates three parallel execution processes: process 1 (bound to 0x10), process 2 (bound to 0x12), and process 3 (bound to 0x20).

[0098] 2. Firmware upgrade data is a set of binary data used to update the firmware version of the vehicle controller. It contains the program code, configuration parameters, verification information (such as hash values), and version identifier (such as V2.3) of the new firmware. It is the core data for optimizing controller functions or fixing vulnerabilities. It is obtained by the upgrade module receiving the target parallel upgrade sequence from the cloud server, synchronously parsing the firmware upgrade data packets (usually compressed and encrypted) encapsulated in the sequence, decrypting and decompressing them, and storing them in a local cache (such as Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM)). For example, the firmware upgrade data for the motor controller is "V2.3 version driver", 512KB in size, containing motor torque control optimization code and new fault diagnosis logic.

[0099] 3. Firmware data fragments are small data blocks formed by the upgrade module dividing the firmware upgrade data into preset sizes (e.g., 128 bytes, 512 bytes). Each fragment contains a fragment number (for reassembly), data payload, and fragment check code (e.g., Cyclic Redundancy Check, CRC). This reduces the amount of data transmitted in a single transmission and decreases the risk of transmission failure. The fragmentation unit of the upgrade module divides the firmware upgrade data into fixed lengths (e.g., 128 bytes), pads the last fragment shorter than the fixed length with zeros, and adds a sequence number (1 to N) and a CRC code to each fragment. For example, 512KB of motor controller firmware upgrade data, fragmented into 128-byte segments, can generate 4096 firmware data fragments (fragment 1 to fragment 4096), where fragment 1 has a sequence number of 0x0001 and a CRC code of 0x3A7B.

[0100] 4. Generating target data frames based on the diagnostic logic address corresponding to each parallel execution process involves each parallel execution process encapsulating the corresponding firmware data fragment and flash control instructions (from the target parallel upgrade sequence) into a frame structure conforming to the Ethernet Protocol, based on its own bound diagnostic logic address. The frame header contains the diagnostic logic address as a target identifier, ensuring that the embedded gateway can recognize the target controller. This is achieved by the parallel execution process calling the data frame encapsulation interface to generate frame data in the format of "frame header (containing diagnostic logic address) + flash control instructions + firmware data fragment + frame trailer (checksum)". The flash control instructions are extracted from the target parallel upgrade sequence (such as erase instructions and data transmission instructions). For example, the target data frame generated by process 1 (bound to 0x10) includes: frame header (diagnostic logic address 0x10) + flash control instruction "0x36 (data transmission service)" + firmware data fragment 1 (motor controller fragment 1) + frame trailer (CRC code 0x5D8E).

[0101] 5. The target data frame may include multiple firmware data fragments and flash control commands corresponding to the diagnostic logic address in the target parallel upgrade sequence. This description clearly defines the composition of the target data frame: it contains one or more consecutive firmware data fragments (reducing the number of frames and improving transmission efficiency), as well as flash control instructions (such as data transmission instructions and verification instructions) that match the diagnostic logic address. Together, they constitute a complete data unit that can be parsed by the embedded gateway. For example, the target data frame generated by process 2 (bound to 0x12) includes: frame header (0x12) + flash control instruction "0x36" + firmware data fragment 1 (window controller fragment 1) + firmware data fragment 2 (window controller fragment 2) + frame tail (CRC code 0x9F2C), where "0x36" is a dedicated data transmission instruction for 0x12 in the target parallel upgrade sequence.

[0102] 6. The upgrade module utilizes a single Ethernet communication link (e.g., a 100Mbps automotive Ethernet) to alternately transmit target data frames carrying different diagnostic logical addresses to the embedded gateway. Through a time-slice rotation mechanism, it alternately sends target data frames from different parallel execution processes (i.e., frames carrying different addresses such as 0x10, 0x12, and 0x20 are sent sequentially), enabling concurrent transmission of firmware data from multiple controllers (logically parallel, but physically time-division multiplexing). This is achieved by the upgrade module's link scheduling unit allocating a fixed time slice (e.g., 1ms) to each parallel execution process. Within their respective time slices, each process sends target data frames through the Ethernet Physical Layer Interface, avoiding frame collisions. For example, the upgrade module sends the frame (0x10) of process 1 in the 1ms, the frame (0x12) of process 2 in the 2ms, the frame (0x20) of process 3 in the 3ms, and then sends the frame of process 1 again in the 4ms (fragment 2 of 0x10), and so on, until all frames are transmitted.

[0103] 7. The embedded gateway routes received target data frames to the corresponding vehicle controller based on the diagnostic logic address. Upon receiving the target data frame, the embedded gateway parses the diagnostic logic address in the frame header, queries a preset "diagnostic logic address-network segment mapping table" (e.g., 0x10 corresponds to Controller Area Network Flexible Data Rate Protocol (CAN) segment 1, 0x12 corresponds to Local Interconnect Network (LIN) segment 2), converts the Ethernet frame to the corresponding network segment's protocol frame (e.g., CAN FD frame, LIN frame), and forwards it to the target vehicle controller. This is achieved by the embedded gateway's Protocol Conversion Unit extracting the diagnostic logic address through address resolution, matching it against the mapping table to determine the target network segment and protocol type, and then performing data format conversion and forwarding. For example, the embedded gateway receives the target data frame (address 0x10) from process 1, looks up the mapping table to find that 0x10 corresponds to CANFD network segment 1 (baud rate 2Mbps), then converts the Ethernet frame into a CAN FD frame (ID is 0x7E0, data field is fragment 1 data), and sends it to the motor controller through the CAN FD physical layer interface.

[0104] By implementing the above embodiments, multiple parallel execution processes are created in the upgrade module, and firmware data is fragmented and encapsulated using diagnostic logical addresses as distinguishing identifiers. This enables independent communication and concurrent control of different controllers, thereby improving the bandwidth utilization of a single Ethernet communication link. It also allows the embedded gateway to automatically route target data frames based on diagnostic addresses, avoiding communication conflicts and link congestion, and ensuring the orderliness and real-time performance of data transmission. Compared to traditional serial upgrade methods, it can achieve process-level parallelism and data-level distribution parallelism, and can improve firmware distribution speed and the ability to simultaneously flash multiple controllers.

[0105] In some embodiments, the aforementioned method of alternately transmitting target data frames carrying different diagnostic logic addresses to the embedded gateway via a single Ethernet communication link may include: obtaining a first bandwidth of the single Ethernet communication link and a second bandwidth of the communication link between the embedded gateway and the downstream vehicle controller; determining a first data transmission capacity based on the first bandwidth and a second data transmission capacity based on the second bandwidth; and, when the first data transmission capacity is greater than or equal to a first preset capacity and the second data transmission capacity is greater than or equal to a second preset capacity, alternately transmitting target data frames carrying different diagnostic logic addresses to the embedded gateway via the single Ethernet communication link.

[0106] In some examples, the first bandwidth is the maximum data transmission rate of a single Ethernet communication link between the upgrade module and the embedded gateway, which can be measured in megabits per second (Mbps). It is a core indicator for measuring the data carrying capacity of the link. The first bandwidth can be calculated by sending probe frames through the link monitoring unit of the upgrade module and counting the number of bits successfully transmitted per unit time. Alternatively, the preset nominal bandwidth of the link can be extracted from the network topology configuration information. For example, if the single Ethernet communication link between the upgrade module and the embedded gateway 1 is a 100Mbps vehicle Ethernet, its first bandwidth is 100Mbps. The second bandwidth is the maximum data transmission rate of the communication link between the embedded gateway and the connected vehicle controller. The unit can be megabits per second (Kbps) or kilobits per second (kbps), reflecting the upper limit of data transmission within the network segment. The second bandwidth can be obtained by retrieving the preset bandwidth parameters of each network segment from the network topology configuration information through the upgrade module, or by reading the real-time bandwidth of the network segment through the diagnostic interface of the embedded gateway. For example, the second bandwidth of the CANFD network segment connected to the motor controller of embedded gateway 1 is 2 Mbps, and the second bandwidth of the LIN network segment connected to the window controller is 20 kbps. The first data transmission capacity is the maximum amount of data that a single Ethernet communication link can actually transmit per unit time, calculated based on the first bandwidth. The unit can be megabytes per second (MB / s), which is a key indicator for evaluating whether the link can support parallel transmission. The first data transmission capacity = first bandwidth × (1 - protocol overhead percentage) ÷ 8 (bit to byte conversion factor), where the protocol overhead percentage can be taken as 20% (Ethernet protocol overhead is about 18%-22%). For example, when the first bandwidth is 100Mbps, the first data transmission capacity = 100Mbps × 80% ÷ 8 = 10MB / s (that is, 10 megabytes of data can be transmitted per second). The second data transmission capacity is the maximum amount of data that can actually be transmitted per unit time between the embedded gateway and the downstream controller based on the second bandwidth. The unit can be kilobytes per second (KB / s). The second data transmission capacity = second bandwidth × (1 - network segment protocol overhead percentage) ÷ 8, where the CANFD protocol overhead percentage is approximately 15% and the LIN protocol overhead percentage is approximately 25%. For example, when the second bandwidth of the CANFD network segment is 2Mbps, the second data transmission capacity = 2Mbps × 85% ÷ 8 = 212.5KB / s; when the second bandwidth of the LIN network segment is 20kbps, the second data transmission capacity = 20kbps × 75% ÷ 8 = 1.875KB / s.

[0107] The first preset capacity is the minimum data transmission capacity threshold required by a single Ethernet communication link to ensure that all target data frames of the target parallel flashing node can be transmitted within the expected time. It is preset by the cloud server based on the total size of the target data frames, the transmission time requirements, and the number of concurrent controllers. It can be calculated based on the following formula: First preset capacity = (Total firmware data size of all controllers ÷ Expected transmission time) × Security factor (can be 1.2), and stored in the target parallel upgrade sequence, which is parsed and obtained by the upgrade module. For example, if the total size of the firmware data to be transmitted by the target parallel flashing node is 10MB and the expected transmission time is 5 seconds, then the first preset capacity = (10MB ÷ 5s) × 1.2 = 2.4MB / s. The second preset capacity is the minimum data transmission capacity threshold required by the communication link of a single network segment to ensure that the vehicle controller within a single network segment can receive the target data frame in a timely manner (avoiding fragment accumulation or timeout). This threshold is preset by the cloud server based on the firmware data fragment size of the corresponding controller, the transmission frequency, and the communication needs of other devices within the network segment. It can be calculated using the following formula: Second preset capacity = (Firmware fragment size of a single controller × Number of fragments transmitted per second) × Safety factor (usually 1.5), and stored in the network topology configuration information for retrieval by the upgrade module. For example, if the motor controller of the CANFD network segment needs to receive 10 fragments of 128 bytes per second, then the second preset capacity = (128 bytes × 10 ÷ 1s) × 1.5 = 1920 bytes / second ≈ 1.875KB / s. Simultaneously, the actual carrying capacity (first data transmission capacity) of a single Ethernet communication link must not be lower than the required minimum threshold (first preset capacity), and the actual carrying capacity (second data transmission capacity) of each network segment link must not be lower than the corresponding threshold (second preset capacity) to ensure that there is no packet loss or delay caused by insufficient bandwidth during parallel transmission, and then alternating transmission can be performed.

[0108] Through the implementation of the above embodiments, the bandwidth capacity of the single Ethernet communication link and the gateway-connected link is dynamically monitored, and the data transmission conditions are judged based on the real-time transmission capabilities of different communication channels. Under the premise that system resources allow, the data frames can be transmitted alternately in parallel, thereby realizing link-level load balancing and bandwidth adaptive scheduling. This can effectively avoid data blocking or packet loss caused by network bottlenecks or communication rate mismatch, and ensure the communication stability and data integrity of multiple vehicle controllers during the parallel flashing process. This makes the upgrade process more efficient and reliable, and is particularly suitable for the complex multi-segment communication architecture in new energy vehicles.

[0109] In some embodiments, the aforementioned vehicle controller firmware upgrade method may further include: during the parallel firmware flashing process, detecting the cache utilization rate of the embedded gateway; if the cache utilization rate is greater than or equal to a preset utilization rate threshold, reducing the rate at which firmware upgrade data is transmitted to the embedded gateway via a single Ethernet communication link; and if the cache utilization rate is less than the preset utilization rate threshold, increasing the rate at which firmware upgrade data is transmitted to the embedded gateway via a single Ethernet communication link.

[0110] In some examples, cache utilization is the percentage of occupied cache space to the total cache capacity within the embedded gateway's built-in cache. This reflects the current cache load of the embedded gateway and is a core criterion for determining whether the data transmission rate needs adjustment. The embedded gateway's cache primarily stores target data frames transmitted by the upgrade module via a single Ethernet communication link. After protocol conversion (such as Ethernet to Controller Area Network Flexible Data Rate Protocol), these frames are forwarded to the downstream vehicle controller. The preset utilization threshold is a pre-set critical value for cache utilization to prevent embedded gateway cache overflow (leading to data loss) or cache idleness (leading to bandwidth waste). This can be a fixed percentage, such as 70%, and serves as the standard for the upgrade module to adjust the data transmission rate.

[0111] When the cache utilization rate is greater than or equal to the preset utilization rate threshold, it indicates that the embedded gateway's cache is close to or has reached its load limit. If transmission continues at the current rate, new target data frames will be lost because they cannot be stored in the cache. Therefore, the transmission rate needs to be reduced, such as by extending the sending interval of firmware data fragments and reducing the number of fragments in a single transmission, to allow the embedded gateway sufficient time to complete the protocol conversion and forwarding of cached data. When the cache utilization rate is less than the preset utilization rate threshold, it indicates that the embedded gateway's cache still has free space, and the current transmission rate is not fully utilizing the bandwidth of a single Ethernet link. Therefore, the transmission rate can be increased, such as by shortening the fragment sending interval and increasing the number of fragments in a single transmission, to shorten the overall upgrade time. For example, if the initial transmission rate of the upgrade module is 10 megabytes per second, and the cache utilization rate of embedded gateway 1 is detected to rise to 75% (≥70% threshold), the rate will be reduced by 20% to 8MB / s. If the cache utilization rate is subsequently detected to drop to 60% (<70% threshold), the rate will be increased by 12.5% ​​to 9MB / s.

[0112] By implementing the above embodiments, the cache utilization rate of the embedded gateway is detected in real time during the parallel flashing process, and the data transmission rate is dynamically adjusted based on it. This enables adaptive control of the transmission load, thereby preventing cache overflow, data accumulation, or communication delays. It can effectively balance the relationship between the cloud data delivery rate and the gateway processing capacity, ensuring the continuity and stability of parallel upgrade tasks. In the resource-constrained embedded gateway architecture of new energy vehicles, it can not only improve the vehicle system's anti-congestion capability but also enhance the reliability and security of data transmission during the vehicle upgrade process.

[0113] Furthermore, as an implementation of the aforementioned method embodiments, this application also provides an on-board controller firmware upgrade device for implementing the aforementioned method embodiments. This device embodiment corresponds to the aforementioned method embodiments. For ease of reading, this on-board controller firmware upgrade device embodiment will not repeat the details of the aforementioned method embodiments one by one, but it should be understood that the device in this application embodiment can correspondingly implement all the contents of the aforementioned method embodiments. For example... Figure 4 As shown, the vehicle controller firmware upgrade device 40 includes a sequence receiving unit 401 and a flashing execution unit 402. The sequence receiving unit 401 is used to receive a target parallel upgrade sequence sent by a cloud server. The target parallel upgrade sequence is generated by the cloud server based on each target parallel flashing node in the parallel flashing matrix. The aforementioned parallel flashing matrix defines multiple parallel flashing nodes. Each parallel flashing node is associated with a group of vehicle controllers to be upgraded. Different vehicle controllers correspond to different communication network segments. Each communication network segment belongs to an embedded gateway. Each embedded gateway may include at least one communication network segment. The flashing execution unit 402 is used to concurrently send firmware upgrade data to multiple vehicle controllers corresponding to the target parallel flashing nodes through the upgrade module, so as to perform firmware flashing on the multiple vehicle controllers corresponding to the target parallel flashing nodes in parallel.

[0114] In some embodiments, the flashing execution unit 402 is further configured to: create multiple parallel execution processes corresponding to the target parallel flashing node through the upgrade module; divide the firmware upgrade data into multiple firmware data fragments; generate a target data frame based on the diagnostic logic address corresponding to each parallel execution process, wherein the target data frame includes multiple firmware data fragments and flashing control instructions corresponding to the diagnostic logic address in the target parallel upgrade sequence; alternately transmit target data frames carrying different diagnostic logic addresses to the embedded gateway through a single Ethernet communication link; and route the received target data frames to the corresponding vehicle controller through the embedded gateway based on the diagnostic logic address.

[0115] In some embodiments, the flashing execution unit 402 is further configured to obtain the first bandwidth of the single Ethernet communication link and the second bandwidth of the communication link between the embedded gateway and the downstream vehicle controller; determine the first data transmission capacity based on the first bandwidth and determine the second data transmission capacity based on the second bandwidth; and when the first data transmission capacity is greater than or equal to the first preset capacity and the second data transmission capacity is greater than or equal to the second preset capacity, alternately transmit target data frames carrying different diagnostic logic addresses to the embedded gateway through the single Ethernet communication link.

[0116] In some embodiments, the flashing execution unit 402 is further configured to detect the cache utilization rate of the embedded gateway during the parallel firmware flashing process; if the cache utilization rate is greater than or equal to a preset utilization rate threshold, reduce the rate of transmitting firmware upgrade data to the embedded gateway through a single Ethernet communication link; and if the cache utilization rate is less than the preset utilization rate threshold, increase the rate of transmitting firmware upgrade data to the embedded gateway through a single Ethernet communication link.

[0117] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, will cause the processor to perform any step of the vehicle controller firmware upgrade method provided in this application.

[0118] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0119] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0120] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0121] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0122] like Figure 5 As shown, this application also provides an electronic device 50, including a memory 510, a processor 520, and a computer program 511 stored in the memory 510 and executable on the processor. When the processor 520 executes the computer program 511, it implements any step of the above-described vehicle controller firmware upgrade method.

[0123] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the vehicle controller firmware upgrade method described above.

[0124] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for upgrading the firmware of an on-board controller, characterized in that, The system is applied to a cloud server, which communicates with the vehicle's in-vehicle terminal. The in-vehicle terminal includes an upgrade module and multiple embedded gateways. The upgrade module is connected to each of the embedded gateways via a single Ethernet communication link. The in-vehicle controller firmware upgrade method includes: Obtain a parallel writing matrix, wherein the parallel writing matrix defines multiple parallel writing nodes, each of the parallel writing nodes is associated with a group of vehicle controllers to be upgraded, different vehicle controllers correspond to different communication network segments, each communication network segment belongs to an embedded gateway, and each embedded gateway includes at least one communication network segment. For each target parallel write node in the parallel write matrix, a corresponding target parallel upgrade sequence is generated; The target parallel upgrade sequence corresponding to each target parallel flashing node is sent to the upgrade module. The upgrade module is used to send firmware upgrade data concurrently to multiple vehicle controllers corresponding to the target parallel flashing node based on the target parallel upgrade sequence, so as to perform firmware flashing in parallel on multiple vehicle controllers corresponding to the target parallel flashing node.

2. The vehicle controller firmware upgrade method according to claim 1, characterized in that, The acquisition of the parallel brushing matrix includes: Obtain the network topology configuration information of the target vehicle; Based on the network topology configuration information, the on-board controllers to be upgraded in the target vehicle are grouped to obtain multiple first controller sets; The parallel write matrix is ​​generated based on the plurality of first controller sets, wherein each parallel write node in the parallel write matrix corresponds to one of the first controller sets.

3. The vehicle controller firmware upgrade method according to claim 2, characterized in that, The network topology configuration information includes gateway configuration information and communication network segment information for each vehicle controller; based on the network topology configuration information, the vehicle controllers to be upgraded in the target vehicle are grouped to obtain multiple first controller sets, including: Based on the gateway configuration information, the vehicle controllers to be upgraded are filtered to obtain a second set of controllers, wherein the second set of controllers includes vehicle controllers connected to the embedded gateway; Based on the communication network segment information, the vehicle controllers in the second controller set are grouped to obtain multiple controller subsets, wherein the vehicle controllers in different controller subsets belong to different communication network segments; Based on the plurality of controller subsets, the plurality of first controller sets are determined, wherein the vehicle controllers in any of the first controller sets satisfy the communication topology conditions for parallel writing.

4. The vehicle controller firmware upgrade method according to claim 3, characterized in that, The step of grouping the on-board controllers to be upgraded in the target vehicle based on the network topology configuration information to obtain multiple first controller sets also includes: Based on the gateway configuration information, the vehicle controllers to be upgraded are filtered to obtain a third controller set, wherein the third controller set includes vehicle controllers as independent upgrade units; The step of determining the plurality of first controller sets based on the plurality of controller subsets includes: Based on the third controller set and the plurality of controller subsets, the plurality of first controller sets are determined.

5. The vehicle controller firmware upgrade method according to claim 4, characterized in that, The step of determining the plurality of first controller sets based on the third controller set and the plurality of controller subsets includes: Determine the number of vehicle controllers in each controller subset, and determine the maximum number among all the numbers as the target number; Create an initial set corresponding to the target number, assign the vehicle controllers in the third controller set to any of the initial controller sets, and assign the vehicle controllers in each controller subset to the multiple initial controller sets in a preset order to obtain multiple first controller sets.

6. The vehicle controller firmware upgrade method according to claim 2, characterized in that, The step of generating the parallel brush matrix based on the plurality of first controller sets includes: Based on preset parallel writing constraints, the parallel feasibility of the multiple first controller sets is verified. The parallel writing constraints include at least one of network bandwidth constraints, gateway processing capacity constraints, and inter-controller dependency constraints. If the parallel feasibility verification passes, the multiple sets of first controllers will be mapped to corresponding parallel write nodes. According to the preset node execution order, multiple parallel writing nodes are arranged to form the parallel writing matrix, wherein the preset node execution order is determined based on the upgrade priority and network topology of each first controller set.

7. The vehicle controller firmware upgrade method according to claim 1, characterized in that, The step of generating a corresponding target parallel upgrade sequence for each target parallel write node in the parallel write matrix includes: For each target parallel writing node in the parallel writing matrix, obtain the diagnostic logic addresses of multiple vehicle controllers corresponding to the target parallel writing node; Based on the diagnostic logical address, a parallel flashing instruction set corresponding to the target parallel flashing node is generated. The parallel flashing instruction set is used to instruct the vehicle terminal to send flashing control commands concurrently to the multiple vehicle controllers under the single Ethernet communication link, using multiple diagnostic logical addresses as distinguishing identifiers. The vehicle communication mute command, the parallel flashing command set, and the vehicle communication unmute command are sequentially encapsulated and integrated to obtain the target parallel upgrade sequence corresponding to the target parallel flashing node.

8. The vehicle controller firmware upgrade method according to claim 7, characterized in that, The step of generating the parallel write instruction set corresponding to the target parallel write node based on the diagnostic logical address includes: Based on the diagnostic logical address, a parallel pre-programming sequence corresponding to the target parallel flashing node is generated. The parallel pre-programming sequence is used to instruct the vehicle terminal to send erase instructions and storage area initialization instructions in parallel under the single Ethernet communication link, using multiple diagnostic logical addresses as target identifiers, so that the firmware storage area of ​​the multiple vehicle controllers enters a writable state. Based on the diagnostic logic address, a parallel flashing sequence corresponding to the target parallel flashing node is generated. The parallel flashing sequence is used to instruct the vehicle terminal to transmit firmware data packets in parallel in a fragmented manner, and to control data reception, writing and progress synchronization according to each of the diagnostic logic addresses. Based on the diagnostic logical address, a parallel verification sequence corresponding to the target parallel flashing node is generated. The parallel verification sequence is used to instruct the vehicle terminal to send verification request instructions in parallel and to determine the firmware flashing success status of the multiple vehicle controllers based on the verification results or version information returned by the multiple vehicle controllers. The parallel preprogramming sequence, the parallel writing sequence, and the parallel verification sequence are combined in sequence to form the parallel writing instruction set corresponding to the target parallel writing node.

9. The vehicle controller firmware upgrade method according to any one of claims 1 to 8, characterized in that, The cloud servers include over-the-air (OTA) cloud servers and remote virtual data center cloud servers. The acquisition of the parallel brushing matrix includes: The cloud server obtains the parallel brushing matrix through the aforementioned over-the-air download technology; The step of generating a corresponding target parallel upgrade sequence for each target parallel write node in the parallel write matrix includes: The remote virtual data center cloud server receives the parallel brushing matrix sent by the over-the-air download technology cloud server, and generates a corresponding target parallel upgrade sequence for each target parallel brushing node in the parallel brushing matrix. Sending the target parallel upgrade sequence corresponding to each target parallel write node to the upgrade module includes: The remote virtual data center cloud server sends the target parallel upgrade sequence corresponding to each target parallel writing node to the upgrade module.

10. A method for upgrading the firmware of an on-board controller, characterized in that, Applied to a target vehicle, the vehicle's on-board terminal includes an upgrade module and an embedded gateway. The upgrade module and the embedded gateway are connected via a single Ethernet communication link. The on-board controller firmware upgrade method includes: The system receives a target parallel upgrade sequence issued by the cloud server. The target parallel upgrade sequence is generated by the cloud server based on each target parallel write node in the parallel write matrix. The parallel write matrix defines multiple parallel write nodes. Each parallel write node is associated with a group of vehicle controllers to be upgraded. Different vehicle controllers correspond to different communication network segments. Each communication network segment belongs to an embedded gateway. Each embedded gateway includes at least one communication network segment. The upgrade module concurrently sends firmware upgrade data to multiple vehicle controllers corresponding to the target parallel flashing node, so as to perform firmware flashing in parallel on the multiple vehicle controllers corresponding to the target parallel flashing node.

11. The vehicle controller firmware upgrade method according to claim 10, characterized in that, The step of concurrently sending firmware upgrade data to multiple vehicle controllers corresponding to the target parallel flashing node through the upgrade module includes: The upgrade module creates multiple parallel execution processes corresponding to the target parallel writing node; The firmware upgrade data is divided into multiple firmware data fragments; A target data frame is generated based on the diagnostic logic address corresponding to each of the parallel execution processes, wherein the target data frame includes the plurality of firmware data fragments and the flash control instruction corresponding to the diagnostic logic address in the target parallel upgrade sequence; Through the single Ethernet communication link, the target data frames carrying different diagnostic logic addresses are alternately transmitted to the embedded gateway; The embedded gateway routes the received target data frame to the corresponding vehicle controller based on the diagnostic logic address.

12. The vehicle controller firmware upgrade method according to claim 11, characterized in that, The step of alternately transmitting target data frames carrying different diagnostic logic addresses to the embedded gateway via the single Ethernet communication link includes: Obtain the first bandwidth of the single Ethernet communication link and the second bandwidth of the communication link between the embedded gateway and the lower-mounted vehicle controller; The first data transmission capacity is determined based on the first bandwidth, and the second data transmission capacity is determined based on the second bandwidth; When the first data transmission capacity is greater than or equal to the first preset capacity and the second data transmission capacity is greater than or equal to the second preset capacity, the target data frames carrying different diagnostic logic addresses are alternately transmitted to the embedded gateway through the single Ethernet communication link.

13. The vehicle controller firmware upgrade method according to any one of claims 10 to 12, characterized in that, The vehicle controller firmware upgrade method also includes: During the parallel firmware flashing process, the cache usage rate of the embedded gateway is detected; If the cache utilization rate is greater than or equal to a preset utilization rate threshold, reduce the rate at which the firmware upgrade data is transmitted to the embedded gateway via the single Ethernet communication link; If the cache utilization rate is less than the preset utilization rate threshold, the rate at which the firmware upgrade data is transmitted to the embedded gateway via the single Ethernet communication link is increased.

14. An electronic device comprising: The memory and processor are characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the vehicle controller firmware upgrade method as described in any one of claims 1 to 13.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the vehicle controller firmware upgrade method as described in any one of claims 1 to 13.

Images