DOIP-based Parallel Flashing Method and Device for Vehicle-Mounted Multi-ECUs

Abstract

This application discloses a parallel flashing method for multiple ECUs in an vehicle based on DOIP (Domain-Oriented Integrated Circuit). This method is executed by the OTA (Over-The-Air) master controller and includes: acquiring flashing tasks; dynamically grouping ECUs to be flashed based on multi-dimensional constraint rules to generate a parallel flashing task graph; establishing diagnostic communication sessions in parallel according to the parallel flashing task graph, and transmitting flashing data in parallel using an independent flow control strategy; after data transmission is completed, performing an atomic commit operation based on the collected flashing status, and uniformly controlling software activation or rollback. This application achieves parallel flashing of multiple DOIP controllers by dynamically grouping flashing tasks to identify ECUs that can be flashed in parallel, thereby establishing independent communication channels and data flow control strategies. This solves the problem of long latency in existing serial flashing methods, significantly shortening the vehicle software update window time, improving flashing efficiency, and enhancing user experience.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more specifically, to a method and apparatus for parallel flashing of multiple ECUs in a vehicle based on DOIP. Background Technology

[0002] With the development of intelligent connected vehicles, the number of on-board electronic control units is increasing daily, and software updates via OTA (Over-the-Air Technology) have become commonplace. The DOIP protocol, due to its high bandwidth, has become the mainstream communication protocol for next-generation vehicle diagnostics and flashing.

[0003] Currently, ECU flashing based on DOIP typically uses a serial approach, where the OTA master controller (such as a gateway) sequentially establishes a diagnostic session with each ECU, completes secure access, transmits data, verifies, and activates it. For modern cars with dozens or even hundreds of ECUs, this method is time-consuming (potentially exceeding 2 hours), provides a poor user experience, and leaves the vehicle unavailable for an excessively long period, increasing the risk of upgrade failure due to external interference (such as a depleted battery).

[0004] While some parallel flashing solutions exist in existing technologies, they typically only support parallel flashing of the DOIP controller and the CAN controller. Because the CAN controller flashing time is relatively short, the truly time-consuming DOIP controller flashing process still has to be performed serially, failing to fundamentally solve the problem of excessively long upgrade times. Summary of the Invention

[0005] This application aims to overcome the inefficiency of existing serial flashing techniques and provides a DOIP-based parallel flashing method and apparatus for multiple ECUs in vehicles, enabling safe, efficient, and reliable parallel updates of vehicle-level software and significantly shortening the flashing time window. To achieve the above objectives, this application adopts the following technical solution.

[0006] In a first aspect, embodiments of this application provide a parallel flashing method for multiple ECUs in a vehicle based on DOIP, executed by an OTA master controller, wherein the OTA master controller is connected to multiple ECUs to be flashed via an in-vehicle Ethernet; the parallel flashing method specifically includes:

[0007] The flashing preprocessing step involves obtaining a flashing task containing upgrade data packages for multiple ECUs to be flashed, and dynamically grouping the multiple ECUs to be flashed based on multi-dimensional constraint rules to generate a parallel flashing task graph; wherein, the parallel flashing task graph defines at least one parallel group and the serial flashing order of ECUs within each parallel group.

[0008] The parallel session and data transmission steps involve establishing independent diagnostic communication sessions for each parallel group in parallel, based on the parallel flashing task diagram, and employing an independent flow control strategy to transmit flashing data in parallel to the ECUs within each parallel group.

[0009] The collaborative state synchronization step involves collecting the flashing status of each ECU after completing the data transmission of all parallel groups, and performing an atomic commit operation based on the flashing status to uniformly control all ECUs to perform software activation or uniformly execute rollback operations.

[0010] Furthermore, in the brushing preprocessing step, the multidimensional constraint rules include at least one of the following: communication channel independence rules, functional safety and dependency rules, and power load estimation rules.

[0011] The communication channel independence rule is used to allocate ECUs located on different physical links or different virtual local area networks to different parallel groups in order to maximize the use of network bandwidth;

[0012] The functional safety and dependency rules are used to assign ECUs with mandatory sequential flashing dependencies to serial subgroups within the same parallel group, and to treat the serial subgroup as a whole task node for parallel scheduling.

[0013] The power load estimation rule is used to estimate the total power consumption of each parallel group based on the rated power consumption of the ECU in flashing mode, and to ensure that the total power consumption of the currently activated parallel group does not exceed the preset safety threshold of the vehicle power system.

[0014] Furthermore, in the parallel session and data transmission steps, the independent flow control strategy includes:

[0015] An independent sliding window is maintained for each parallel group, and the size of the sliding window is dynamically adjusted based on the real-time status of the communication link corresponding to each parallel group to control the data transmission rate of each parallel group; the real-time status includes at least one of data response delay, message retransmission rate, or network transmission queue depth.

[0016] Furthermore, the parallel session and data transmission steps also include:

[0017] When establishing independent diagnostic communication sessions for each parallel group in parallel, a staggered scheduling strategy is adopted to initiate security access requests to each ECU in parallel. For security access requests whose computational complexity exceeds a preset complexity threshold, a random or sequential offset with a preset small offset threshold is applied in the timing to avoid excessive instantaneous load on the OTA master controller.

[0018] Furthermore, in the cooperative state synchronization step, the atomic commit operation includes:

[0019] Once all ECUs in all parallel groups have reported successful data flashing verification, activation commands are sent to all ECUs in parallel.

[0020] If any ECU reports a flashing failure, the rollback range is determined based on the attributes of the failed ECU and the preset atomic group strategy, and all ECUs within the rollback range are restored to the software version before the flashing.

[0021] Furthermore, the parallel session and data transmission steps also include:

[0022] During data transmission, the flashing progress of each ECU and the status of the power system are monitored in real time.

[0023] When the voltage or current parameters of the power system are detected to be lower than the preset current-voltage threshold, the number of currently executing parallel groups and / or the data transmission rate are dynamically adjusted according to the preset power management strategy.

[0024] Furthermore, the brushing preprocessing step also includes:

[0025] A global pre-check is performed on the vehicle to confirm that the vehicle meets the basic conditions for entering the flashing mode; the basic conditions include at least one of the following: vehicle gear status, vehicle speed, battery charge, and diagnostic session status.

[0026] Once the global pre-check passes, the parallel brushing task graph is generated based on the multi-dimensional constraint rules.

[0027] Furthermore, in the collaborative state synchronization step, the write state includes data transmission completion status, data verification result status, and / or write log information;

[0028] The parallel flushing method further includes: after the atomic commit operation is completed, uploading the flushing status and the execution log of this flushing to the cloud server for upgrading task tracking and subsequent flushing strategy optimization.

[0029] Secondly, embodiments of this application provide a DOIP-based in-vehicle multi-ECU parallel flashing device, wherein the parallel flashing device is an OTA master controller, specifically comprising:

[0030] The grouping module is used to acquire a flashing task containing upgrade data packages of multiple ECUs to be flashed, and dynamically group the multiple ECUs to be flashed based on multi-dimensional constraint rules to generate a parallel flashing task graph; wherein, the parallel flashing task graph defines at least one parallel group and the serial flashing order of ECUs within each parallel group.

[0031] The parallel transmission module is used to establish independent diagnostic communication sessions for each parallel group in parallel according to the parallel flashing task diagram, and to use an independent flow control strategy to transmit flashing data in parallel to the ECUs in each parallel group.

[0032] The collaborative control module is used to collect the flashing status of each ECU after completing the data transmission of all parallel groups, and to perform an atomic commit operation based on the flashing status, so as to uniformly control all ECUs to perform software activation or uniformly execute rollback operation.

[0033] Thirdly, embodiments of this application provide an electronic device, including: one or more processors;

[0034] A memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are able to implement the steps of the parallel write method described in any of the preceding claims.

[0035] Fourthly, embodiments of this application provide a computer-readable medium storing a computer program, which, when executed by a processor, can implement the steps of the parallel writing method described in any of the preceding claims.

[0036] This application discloses a parallel flashing method for multiple ECUs in an vehicle based on DOIP (Domain-Oriented Integrated Circuit). This method is executed by the OTA (Over-The-Air) master controller and includes: acquiring flashing tasks; dynamically grouping ECUs to be flashed based on multi-dimensional constraint rules to generate a parallel flashing task graph; establishing diagnostic communication sessions in parallel according to the parallel flashing task graph, and transmitting flashing data in parallel using an independent flow control strategy; after data transmission is completed, performing an atomic commit operation based on the collected flashing status, and uniformly controlling software activation or rollback. This application achieves parallel flashing of multiple DOIP controllers by dynamically grouping flashing tasks to identify ECUs that can be flashed in parallel, thereby establishing independent communication channels and data flow control strategies. This solves the problem of long latency in existing serial flashing methods, significantly shortening the vehicle software update window time, improving flashing efficiency, and enhancing user experience. Attached Figure Description

[0037] Figure 1 The core flowchart of a DOIP-based parallel flashing method for multiple ECUs in a vehicle is provided in the embodiments of this application;

[0038] Figure 2 A schematic diagram of a DOIP-based vehicle multi-ECU parallel flashing device provided in an embodiment of this application;

[0039] Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0040] To enable those skilled in the art to better understand the technical solutions of this application, exemplary embodiments of this application are described below with reference to the accompanying drawings, including various details of the embodiments of this application to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. Unless otherwise specified, the various embodiments of this application and the features within those embodiments can be combined with each other.

[0041] As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries. The terminology used herein is for describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that when the terms "comprising" and / or "made of" are used herein, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as "connected" or "linked" are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0042] Unless otherwise specified, all terms used in this application (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this application.

[0043] This application provides a parallel flashing method for multiple ECUs in an vehicle based on DOIP, which is executed by an OTA master controller. The OTA master controller can be a gateway, domain controller, or other central node in the vehicle with Ethernet communication and data processing capabilities. The OTA master controller connects to multiple ECUs (Electronic Control Units) to be flashed via in-vehicle Ethernet. These ECUs can be various controllers in the vehicle, such as engine controllers, battery management systems, and smart cockpit controllers.

[0044] like Figure 1 As shown, the method mainly includes three core stages (core steps): the brushing preprocessing and dynamic grouping stage, the parallel session establishment and data transmission stage, and the collaborative verification, activation and global state synchronization stage.

[0045] I. Flashing Preprocessing and Dynamic Grouping Stage. A flashing task containing upgrade data packages for multiple ECUs to be flashed is acquired, and the multiple ECUs to be flashed are dynamically grouped based on multi-dimensional constraint rules to generate a parallel flashing task graph; wherein, the parallel flashing task graph defines at least one parallel group and the serial flashing order of the ECUs within each parallel group.

[0046] In this phase, the OTA main controller first receives the vehicle flashing task package from the cloud. This task package contains upgrade data and metadata for multiple ECUs. Before starting any flashing action, the controller performs a global pre-check on the vehicle to confirm that the vehicle meets the basic conditions for entering flashing mode, such as the vehicle being in P gear, the vehicle speed being 0, the battery charge being higher than the safety threshold, and no other diagnostic devices occupying the bus, ensuring that the flashing task starts in a safe and stable vehicle environment.

[0047] After the global pre-check passes, the controller dynamically groups all ECUs to be flashed based on multi-dimensional constraint rules, generating a parallel flashing task graph. This parallel flashing task graph defines at least one parallel group and the serial flashing order of the ECUs within each parallel group. The purpose of grouping is to identify which ECUs can be flashed simultaneously and which ECUs must be flashed sequentially.

[0048] The above multidimensional constraint rules include at least one of the following three:

[0049] 1. Communication Channel Independence Rule: This rule prioritizes grouping ECUs located on different physical Ethernet links or different virtual LANs (VLANs) into different parallel groups. For example, the OTA master controller identifies ECU_A and ECU_B, which are connected to two different physical ports of an Ethernet switch. According to this rule, they are grouped into different parallel groups to achieve true concurrent transmission and maximize the use of network bandwidth.

[0050] 2. Functional Safety and Dependency Rules: This rule groups ECUs with strict sequential flashing dependencies into serial subgroups within the same parallel group. These serial subgroups participate in parallel scheduling as a single task node. For example, if the controller identifies that the battery management ECU must be flashed before the DC-DC converter ECU, according to this rule, they are placed into the same parallel group as a serial subgroup. Within the parallel group, these ECUs will be flashed sequentially according to a preset order, thus ensuring functional safety.

[0051] 3. Power Load Prediction Rule: This rule estimates the total power consumption of each group based on the ECU's rated power consumption in programming mode, and ensures that the total power consumption of the parallel groups activated at any given time does not exceed the safety threshold of the vehicle's power system. For example, the controller calculates the peak power consumption of each parallel group during flashing, ensuring that the total power consumption of the parallel groups being flashed at the same time does not exceed the safe power supply capacity of the vehicle's 12V battery, to prevent flashing failure due to voltage drops.

[0052] After grouping, the OTA master controller allocates an independent logical write context to each parallel group, including an independent DOIP Socket connection identifier, data buffer, and state machine, to prepare for subsequent parallel data transmission.

[0053] II. Parallel Session Establishment and Data Transmission Phase. Based on the aforementioned parallel flashing task diagram, independent diagnostic communication sessions are established for each parallel group, and independent flow control strategies are employed to transmit flashing data in parallel to the ECUs within each parallel group.

[0054] In this stage, the OTA master controller establishes independent diagnostic communication sessions for each parallel group in parallel, based on the parallel flashing task graph generated in the previous step.

[0055] Specifically, the OTA master controller sends diagnostic session control requests in parallel to the first ECU in each parallel group through multiple independent TCP connections, enabling it to enter an extended diagnostic or programming session. For ECUs that successfully establish a session, a security access process is initiated in parallel. During this process, to avoid excessive instantaneous load, the controller employs a peak-shaving scheduling strategy. For example, when the controller initiates security access requests to multiple ECUs in parallel, it identifies ECUs with more complex security algorithms that require significant CPU time, and applies a small random or sequential offset (such as delaying by 10 ms or 20 ms) to their security access requests, thereby balancing the CPU load of the OTA master controller and ensuring that all security access requests are processed in a timely manner.

[0056] For each parallel group that has been securely accessed, the OTA master controller starts an independent data transmission coroutine or thread to transmit flashing data to the ECUs within its group according to the standard DOIP flashing process of RequestDownload->TransferData->RequestTransferExit.

[0057] In the TransferData subprocess, the OTA master controller implements adaptive flow control based on a sliding window for each parallel group. Specifically, the controller maintains a sending window for each connection in the parallel group, with an initial window size of a preset value W (e.g., 4). The window slides forward only after a positive response to the previous TransferData message is received, allowing the next data block to be sent. Simultaneously, the controller monitors the average latency or message retransmission rate of each connection in real time. If the latency of a connection continues to increase, its sending window is automatically reduced to decrease the data throughput of that channel and prevent it from consuming global bandwidth. For example, when the ECU of group A responds quickly with an average latency of only 5 ms, the controller (hereinafter referred to as the OTA master controller) dynamically increases its window size to 8 to improve its transmission speed; while when the link of group B becomes congested and the response latency increases to 50 ms, the controller immediately reduces its window size to 2 to reduce its transmission rate.

[0058] In addition, the OTA master controller monitors the global network transmission queue depth. If signs of network overload are detected, it dynamically reduces the growth rate of all parallel group transmission windows to ensure network stability at a global level.

[0059] During data transmission, the controller also monitors the flashing progress of each ECU and the power system status in real time. When the voltage or current parameters of the power system are detected to be lower than a preset threshold, the controller dynamically adjusts the number of currently executing parallel groups and / or the data transmission rate according to a preset power management strategy. For example, when the voltage is detected to drop to 11.5 V (below the preset 12 V threshold), the controller immediately reduces the number of currently executing parallel groups from 3 to 1 and halves the sliding window size of the remaining ECUs transmitting data to reduce instantaneous power consumption and prevent battery depletion. Once the voltage recovers, the parallelism and transmission rate are gradually restored.

[0060] III. Collaborative Verification, Activation, and Global State Synchronization Phase. After completing the data transmission of all parallel groups, the flashing status of each ECU is collected, and based on the flashing status, an atomic commit operation is performed to uniformly control all ECUs to perform software activation or uniformly execute rollback operations.

[0061] After all parallel groups have completed data transmission, this phase is responsible for final coordination and state synchronization.

[0062] First, after the ECU data in each parallel group has been downloaded, the verification routine is executed in parallel. Then, the controller executes the "atomic commit" protocol. Specifically, before activating the new software, the OTA master controller checks the flashing status of all ECUs in the parallel group (including data transmission completion status, data verification result status, flashing log information, etc.). Only when all ECUs report successful verification is a reset or activation command sent to all ECUs in parallel to complete the upgrade.

[0063] If any ECU fails at any sub-stage, a tiered rollback mechanism is initiated. The controller determines the rollback scope based on the attributes of the failing ECU and the preset atomic group strategy. For example, if the failing ECU belongs to a non-critical "Comfort Independent Group" and does not affect the functionality of other ECU groups, only ECUs within that group are rolled back to the previous available version. If the failing ECU belongs to the "Powertrain and Safety Atomic Group" (i.e., the critical atomic group), all parallel groups are notified to abort the process, and according to the rollback log, successfully flashed ECUs are rolled back to their pre-flash state to ensure the consistency of the vehicle's software versions.

[0064] After the atomic commit operation is completed, the OTA master controller packages and uploads the detailed status of this flashing (including the flashing results and checksums of each ECU) and execution logs (such as the actual time consumed by each parallel group, window size adjustment records, power supply voltage change curves, etc.) to the cloud server. This data can not only be used to track upgrade tasks and inform users of upgrade results, but also serve as the basis for subsequent data analysis to optimize cloud grouping strategies and power management thresholds for this vehicle model, enabling the system to continuously evolve.

[0065] To implement the above method, refer to Figure 2 This application also provides a DOIP-based in-vehicle multi-ECU parallel flashing device, which is the aforementioned OTA master controller. The parallel flashing device specifically includes:

[0066] (1) Grouping module, which is used to perform the above-mentioned flashing preprocessing steps. This module receives the flashing task sent from the cloud, performs a global pre-inspection of the vehicle, and dynamically generates a parallel flashing task graph based on multi-dimensional constraint rules.

[0067] (2) Parallel transmission module, used to execute the above-mentioned parallel session and data transmission steps. This module establishes diagnostic sessions in parallel according to the task graph generated by the grouping module, and starts an independent data sending thread for each parallel group to implement adaptive flow control and peak scheduling.

[0068] (3) Collaborative control module, used to execute the above-mentioned collaborative status synchronization steps. After the data transmission is completed, this module collects the flashing status of each ECU, performs atomic commit or hierarchical rollback, and is responsible for data synchronization with the cloud after completion.

[0069] Through the coordinated operation of the above modules, the parallel flashing device can safely and efficiently complete the parallel flashing task at the vehicle level.

[0070] In summary, the DOIP-based vehicle multi-ECU parallel flashing method and device provided in this application achieves true parallel flashing of DOIP controllers by intelligently grouping ECUs, establishing independent parallel data channels, and implementing adaptive flow control and collaborative power management. This reduces the vehicle flashing time from hours to minutes, while also possessing high reliability, strong robustness, and good versatility.

[0071] The embodiments of the aforementioned parallel writing method and the embodiments of the aforementioned parallel writing device are identical or related in technical concept, and can be referenced and learned from each other in terms of technical details and technical effects, which will not be repeated here.

[0072] Overall, the advantages of this application compared to the prior art include:

[0073] 1. Improved writing efficiency

[0074] In existing technologies, ECU flashing based on DOIP typically employs a serial approach, where the OTA master controller sequentially establishes a diagnostic session with each ECU, completes secure access, transmits data, performs verification, and activates the ECU. For modern vehicles with dozens or even hundreds of ECUs, this method is time-consuming (potentially exceeding 2 hours), results in a poor user experience, and leaves the vehicle unavailable for an excessively long period.

[0075] This application utilizes a pre-processing step to dynamically group the ECUs to be flashed based on multi-dimensional constraint rules, generating a parallel flashing task graph. Subsequently, it establishes independent diagnostic communication sessions for each parallel group and employs independent flow control strategies to transmit flashing data in parallel. This solution achieves true parallel flashing of multiple DOIP controllers, reducing the vehicle flashing time from hours to minutes, significantly improving flashing efficiency and user experience.

[0076] 2. Guarantee of flashing reliability

[0077] In existing technologies, parallel flashing schemes typically only consider the parallelism of the DOIP controller and the CAN controller, and lack systematic management of communication conflicts, power overload and functional dependencies. They are prone to flashing failures due to resource contention or incorrect dependency order.

[0078] This application introduces multi-dimensional constraint rules during the grouping phase, including communication channel independence rules (grouping ECUs located on different physical links or in different VLANs into different parallel groups to avoid network conflicts), functional safety and dependency rules (grouping ECUs with mandatory sequential dependencies into the same serial subgroup to ensure functional safety), and power load estimation rules (ensuring that the total power consumption of the parallel groups activated at any given time does not exceed the vehicle's power system safety threshold). Simultaneously, during the data transmission phase, adaptive flow control based on a sliding window is employed to dynamically adjust the data rate of each channel, avoiding network congestion. These technical measures mitigate the risks of network conflicts, functional conflicts, and power overload from the outset, significantly improving the reliability of the flashing process.

[0079] 3. Enhanced system robustness

[0080] In existing technologies, there is a lack of sophisticated handling mechanisms for abnormal situations during the flashing process (such as network fluctuations and slow ECU response), which can easily lead to overall upgrade failure. Moreover, once it fails, it often requires a complete vehicle rollback, which has a large impact range and recovery time.

[0081] This application monitors the real-time status of the communication links corresponding to each parallel group (such as data response latency and message retransmission rate) during the data transmission phase, and dynamically adjusts the sliding window size based on these statuses to achieve fine-grained flow control, enhancing adaptability to complex network environments. During the collaborative state synchronization phase, this application executes the "atomic commit" protocol and initiates a tiered rollback mechanism based on the attributes of the failed ECU and the preset atomic group strategy: only the group is rolled back when a non-critical ECU fails, while the entire vehicle is rolled back when a critical atomic group fails. This refined error handling mechanism enhances the system's robustness and minimizes the impact of upgrade failures.

[0082] 4. Improved system security

[0083] In existing technologies, the parallel flashing process lacks coordinated management of the vehicle's power system and the load of the main controller, which may lead to battery depletion due to high power consumption or overload of the main controller due to instantaneous concurrent computing tasks.

[0084] This application monitors the power system status in real time during data transmission. When the voltage or current is detected to be below a preset threshold, it dynamically adjusts the number of currently executing parallel groups and / or the data transmission rate to prevent battery depletion. Simultaneously, during the parallel establishment of diagnostic sessions and secure access phases, a peak-shaving scheduling strategy is employed to time-shift computationally complex secure access requests, balancing the CPU load on the OTA main controller and preventing instantaneous overload from causing controller lag or timeouts. These collaborative management methods significantly improve the system security of the flashing process.

[0085] 5. Realization of Evolutionary Capability

[0086] In existing technologies, flashing strategies (such as grouping methods and flow control parameters) are usually statically configured and cannot be optimized based on actual flashing results, making it difficult to adapt to differences in different vehicle models and hardware configurations.

[0087] After the collaborative state synchronization phase is completed, this application uploads the flashing status of each ECU (including data transmission completion status and data verification result status) and the execution log of this flashing (such as the actual time consumed by each parallel group, window size adjustment records, power supply voltage change curves, etc.) to the cloud server. This data forms a closed-loop feedback, which can be used for subsequent flashing strategy optimization, such as adjusting the cloud group configuration and optimizing power management thresholds, enabling the system to have the ability to continuously learn and self-evolve.

[0088] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 3 As shown in the figure, an electronic device provided in this application embodiment includes: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the parallel writing methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0089] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0090] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0091] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0092] This application also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the parallel writing methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0093] This application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described parallel writing method.

[0094] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0095] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0096] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0097] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing the status information of the computer-readable program instructions. These electronic circuits can execute the computer-readable program instructions to implement various aspects of this application.

[0098] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0099] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0100] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0101] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0102] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0103] Exemplary embodiments have been disclosed in this application, and while specific terminology has been used, it is used only and should be interpreted in a general illustrative sense and is not intended to be limiting. In some embodiments, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A method for parallel flashing of multiple ECUs in a vehicle based on DOIP, characterized in that, The OTA (Over-The-Air) flashing method is executed by the OTA main controller, which is connected to multiple ECUs to be flashed via an in-vehicle Ethernet network. The parallel flashing method specifically includes: The flashing preprocessing step involves obtaining a flashing task containing upgrade data packages for multiple ECUs to be flashed, and dynamically grouping the multiple ECUs to be flashed based on multi-dimensional constraint rules to generate a parallel flashing task graph; wherein, the parallel flashing task graph defines at least one parallel group and the serial flashing order of ECUs within each parallel group. The parallel session and data transmission steps involve establishing independent diagnostic communication sessions for each parallel group in parallel, based on the parallel flashing task diagram, and employing an independent flow control strategy to transmit flashing data in parallel to the ECUs within each parallel group. The collaborative state synchronization step involves collecting the flashing status of each ECU after completing the data transmission of all parallel groups, and performing an atomic commit operation based on the flashing status to uniformly control all ECUs to perform software activation or uniformly execute rollback operations.

2. The parallel writing method according to claim 1, characterized in that, In the brushing preprocessing step, the multidimensional constraint rules include at least one of the following: communication channel independence rules, functional safety and dependency rules, and power load estimation rules. The communication channel independence rule is used to allocate ECUs located on different physical links or different virtual local area networks to different parallel groups in order to maximize the use of network bandwidth; The functional safety and dependency rules are used to assign ECUs with mandatory sequential flashing dependencies to serial subgroups within the same parallel group, and to treat the serial subgroup as a whole task node for parallel scheduling. The power load estimation rule is used to estimate the total power consumption of each parallel group based on the rated power consumption of the ECU in flashing mode, and to ensure that the total power consumption of the currently activated parallel group does not exceed the preset safety threshold of the vehicle power system.

3. The parallel writing method according to claim 1, characterized in that, In the parallel session and data transmission steps, the independent flow control strategy includes: An independent sliding window is maintained for each parallel group, and the size of the sliding window is dynamically adjusted based on the real-time status of the communication link corresponding to each parallel group to control the data transmission rate of each parallel group; the real-time status includes at least one of data response delay, message retransmission rate, or network transmission queue depth.

4. The parallel writing method according to claim 1, characterized in that, The parallel session and data transmission steps also include: When establishing independent diagnostic communication sessions for each parallel group in parallel, a staggered scheduling strategy is adopted to initiate security access requests to each ECU in parallel. For security access requests whose computational complexity exceeds a preset complexity threshold, a random or sequential offset with a preset small offset threshold is applied in the timing to avoid excessive instantaneous load on the OTA master controller.

5. The parallel brushing method according to claim 1, characterized in that, In the cooperative state synchronization step, the atomic commit operation includes: Once all ECUs in all parallel groups have reported successful data flashing verification, activation commands are sent to all ECUs in parallel. If any ECU reports a flashing failure, the rollback range is determined based on the attributes of the failed ECU and the preset atomic group strategy, and all ECUs within the rollback range are restored to the software version before the flashing.

6. The parallel writing method according to claim 1, characterized in that, The parallel session and data transmission steps also include: During data transmission, the flashing progress of each ECU and the status of the power system are monitored in real time. When the voltage or current parameters of the power system are detected to be lower than the preset current-voltage threshold, the number of currently executing parallel groups and / or the data transmission rate are dynamically adjusted according to the preset power management strategy.

7. The parallel brushing method according to claim 1, characterized in that, The brushing preprocessing step also includes: A global pre-check is performed on the vehicle to confirm that the vehicle meets the basic conditions for entering the flashing mode; the basic conditions include at least one of the following: vehicle gear status, vehicle speed, battery charge, and diagnostic session status. Once the global pre-check passes, the parallel brushing task graph is generated based on the multi-dimensional constraint rules.

8. The parallel writing method according to claim 1, characterized in that, In the collaborative state synchronization step, the write state includes data transmission completion status, data verification result status, and / or write log information; The parallel flushing method further includes: after the atomic commit operation is completed, uploading the flushing status and the execution log of this flushing to the cloud server for upgrading task tracking and subsequent flushing strategy optimization.

9. A vehicle-mounted multi-ECU parallel flashing device based on DOIP, characterized in that, The parallel flashing device is an OTA main controller, which specifically includes: The grouping module is used to acquire a flashing task containing upgrade data packages of multiple ECUs to be flashed, and dynamically group the multiple ECUs to be flashed based on multi-dimensional constraint rules to generate a parallel flashing task graph; wherein, the parallel flashing task graph defines at least one parallel group and the serial flashing order of ECUs within each parallel group. The parallel transmission module is used to establish independent diagnostic communication sessions for each parallel group in parallel according to the parallel flashing task diagram, and to use an independent flow control strategy to transmit flashing data in parallel to the ECUs in each parallel group. The collaborative control module is used to collect the flashing status of each ECU after completing the data transmission of all parallel groups, and to perform an atomic commit operation based on the flashing status, so as to uniformly control all ECUs to perform software activation or uniformly execute rollback operation.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it can perform the steps of the parallel brushing method as described in any one of claims 1 to 8.

Images