Vehicle-mounted software transmission memory allocation method and device, terminal equipment and storage medium

Abstract

This application relates to the field of memory management technology, and in particular to a method, apparatus, terminal device, and storage medium for allocating memory for in-vehicle software transmission. The method includes: performing a memory pool initialization operation after system startup; upon receiving an upgrade task from a server, obtaining the task space of the software package to be upgraded and checking the remaining available space in the memory pool; if the remaining available space in the memory pool matches the task space of the software package to be upgraded, obtaining a contiguous memory block of the corresponding size from the memory pool as working memory; writing the received upgrade data into the working memory to perform the upgrade operation, and sending a confirmation signal to the server to synchronize the upgrade status; after the upgrade operation is completed, releasing the working memory back into the memory pool. This solution optimizes the steps in the entire software flashing process, reduces latency, and increases work efficiency.

Description

Technical Field

[0001] This application relates to the field of memory management technology, and in particular to a method, apparatus, terminal device and storage medium for allocating memory for in-vehicle software transmission. Background Technology

[0002] With the accelerated advancement of automotive intelligence and connectivity, the functional complexity of onboard electronic control units (ECUs) is increasing exponentially. The software size of core modules such as Advanced Driver Assistance Systems (ADAS), smart cockpits, and domain controllers has jumped from the traditional megabyte (MB) level to the gigabyte (GB) level, with some controller software packages exceeding 2GB becoming commonplace. This trend poses a severe challenge to software rewriting efficiency throughout the vehicle's lifecycle. Traditional solutions can maintain acceptable upgrade efficiency when the software package is small (<200MB), but when dealing with large software packages of 2GB or more, their inherent limitations are significantly amplified, resulting in substantial accumulated time consumption, low efficiency, and high latency. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method for allocating memory for in-vehicle software transmission, which can effectively solve the problem of high latency.

[0004] In a first aspect, embodiments of this application provide a method for allocating memory for in-vehicle software transmission, characterized in that it includes: The memory pool initialization operation is performed after the system starts; When an upgrade task is received from the server, the task space for the software package to be upgraded is obtained, and the remaining available space in the memory pool is checked. If the remaining available space in the memory pool matches the task space of the software package to be upgraded, then a contiguous memory block of the corresponding size is obtained from the memory pool as working memory. The received upgrade data is written into the working memory to perform the upgrade operation, and a confirmation signal is sent to the server to synchronize the upgrade status. After the upgrade operation is completed, the working memory is released into the memory pool.

[0005] In some embodiments, the initialization of the memory pool after system startup includes: Obtain historical data, and plan and allocate the memory pool size based on the average memory usage, maximum single usage, and volatility in the historical data; Alternatively, the memory pool size can be planned and allocated based on manually entered configuration data.

[0006] In some embodiments, if the remaining available space in the memory pool matches the task space of the software package to be upgraded, then obtaining a contiguous memory block of the corresponding size from the memory pool as working memory includes: If the remaining available space of the memory pool is greater than or equal to the task space, then it is confirmed that the remaining available space of the memory pool matches the task space of the software package to be upgraded. Obtain a contiguous memory block of the same size as the task space from the memory pool and use it as working memory.

[0007] In some embodiments, the method further includes: If the remaining available space of the memory pool is less than the task space of the software package to be upgraded, then calculate the memory difference between the remaining available space of the memory pool and the size of the software package to be upgraded. Based on the memory difference, the system requests additional memory space and incorporates it into the memory pool.

[0008] In some embodiments, the method further includes: The utilization rate of the additional memory space in the memory pool is monitored in real time. When the utilization rate of any memory block in the additional memory space is lower than a preset value, the memory block is released.

[0009] In some embodiments, obtaining the task space of the software package to be upgraded when an upgrade task is received includes: Send a request to the server to request the configuration data packet for the software package to be upgraded; Read the task space of the software package to be upgraded from the configuration data package to determine the task space of the software package to be upgraded.

[0010] In some embodiments, after sending a confirmation signal to the server and synchronizing the upgrade status, the method further includes: If the upgrade status is that the upgrade task is not completed, the memory pool is reused repeatedly to repeatedly execute the operation of writing the received upgrade data into the working memory.

[0011] Secondly, this application also provides an in-vehicle software transmission memory allocation device, comprising: The memory pool allocation module is used to perform memory pool initialization operations after the system starts. The detection module is used to obtain the task space of the software package to be upgraded and check the remaining available space of the memory pool when an upgrade task is received from the server. The matching module is used to obtain a contiguous memory block of the corresponding size from the memory pool as working memory if the remaining available space of the memory pool matches the task space of the software package to be upgraded. The upgrade module is used to write the received upgrade data into the working memory to perform the upgrade operation and send a confirmation signal to the server to synchronize the upgrade status. The release module is used to release the working memory to the memory pool after the upgrade operation is completed.

[0012] Thirdly, this application also provides a terminal device, the terminal device including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the in-vehicle software transmission memory allocation method.

[0013] Fourthly, this application also provides a readable storage medium storing a computer program, which, when executed on a processor, implements the aforementioned vehicle software transmission memory allocation method.

[0014] The embodiments of this application have the following beneficial effects: By building a memory pool and confirming the size of the file to be upgraded before transmission, the number of memory allocation operations during the upgrade process is greatly reduced. Only one memory allocation is needed before the upgrade, and the allocated working memory can participate in the entire upgrade process. This greatly reduces the steps in the data transmission process, thereby reducing transmission time and latency and improving work efficiency. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This paper illustrates a flowchart of a method for allocating memory for in-vehicle software transmission according to an embodiment of this application. Figure 2 This illustrates another flowchart of the vehicle software transmission memory allocation method according to an embodiment of this application; Figure 3 A schematic diagram of a vehicle-mounted software transmission memory allocation device according to an embodiment of this application is shown. Detailed Implementation

[0017] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0018] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0020] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0021] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0022] This application provides a memory allocation method for software updates, specifically applied to software update scenarios. This application pre-allocates memory to obtain a memory pool. When there is a software upgrade task, it allocates corresponding contiguous memory blocks to execute the task for the upgrade operation. Until the upgrade is completed, the memory blocks obtained from the memory pool will not be released, but will be recycled until the upgrade is completed, and then returned to the memory pool.

[0023] The following describes the method for allocating memory for in-vehicle software transmission using specific examples.

[0024] Figure 1 A flowchart illustrating an embodiment of the vehicle software transfer memory allocation method of this application is shown. Exemplarily, the vehicle software transfer memory allocation method includes the following steps: Step S100: After the system starts, the memory pool initialization operation is performed.

[0025] This embodiment applies to a software update scenario for computer devices, primarily focusing on the memory allocation method during the update process. In this embodiment, when the computer device's operating system starts, a memory pool initialization operation is performed, requesting a certain amount of memory from the system memory. This certain amount of memory forms a memory pool.

[0026] As can be understood, in this embodiment, the memory pool refers to the memory blocks pre-allocated from the system after system startup for the execution of subsequent programs, primarily requesting contiguous memory blocks. It is a pre-allocated, fixed-management memory resource pool technology.

[0027] In automotive diagnostics, DoIP (DoIP) is often used for file downloads and program upgrades. Therefore, the system in this embodiment can be considered an on-board diagnostic system, and its corresponding hardware can be an on-board computer.

[0028] During initialization, historical task data can be used to determine how much memory to allocate to the memory pool. For example, data such as average memory usage, maximum single-time usage, and volatility from 100 upgrade tasks over the past week can be collected, and then a theoretical memory size can be calculated. Based on this theoretical memory size, allocation is planned, and data is requested from the system to obtain the memory pool. A memory pool calculated using historical data often closely matches the memory requirements of typical system tasks.

[0029] Furthermore, the system in this embodiment can also accept manually entered configuration data. This configuration data can be entered through a configuration file or manually entered after the system starts by accessing the configuration interface. The memory pool is generated based on the manually entered configuration data. The configuration data can include memory size or even physical memory addresses and other related information.

[0030] Step S200: When an upgrade task is received from the server, the task space of the software package to be upgraded is obtained, and the remaining available space of the memory pool is checked.

[0031] Once the memory pool is initialized, the system will have the ability to process tasks using the memory pool.

[0032] For example, in a software upgrade scenario, when the system receives an upgrade request from the server, it first obtains the size of the software package to be upgraded and checks the remaining available space in the memory pool to determine whether the remaining available space is sufficient for the upgrade task.

[0033] It should be noted that the memory in the memory pool is not only used for software upgrades; it is also used in other task execution scenarios. This embodiment only specifically addresses this latter scenario. Therefore, when an upgrade task is received from the server, the remaining available space in the memory pool is checked, not the total space of the memory pool.

[0034] When receiving an upgrade task from the server, the local system first sends a feedback request to the server, requesting the core data of the software package. This core data can be specifically defined through the communication protocol, requiring the server to provide relevant data information about the software package to be upgraded, such as the total size, block size, number of blocks, verification method, encryption algorithm, and version number of the software upgrade package. After obtaining this information, the local system can perform subsequent data reception and encryption / decryption verification operations based on this information. Therefore, the task space of the software package to be upgraded can be obtained from the data such as the total size, block size, and number of blocks mentioned above.

[0035] Step S300: If the remaining available space of the memory pool matches the task space of the software package to be upgraded, then a contiguous memory block of the corresponding size is obtained from the memory pool as working memory.

[0036] It is understandable that the memory required for an upgrade does not need to be exactly the same as the size of the software package to be upgraded; it only needs to match its download strategy. Specifically, based on the chunk size and number of chunks in the relevant data information mentioned above, it can be determined how the software package to be upgraded is sent in chunks during transmission. It is necessary to determine whether the remaining available space matches the size of the software package to be upgraded. In fact, it is to determine whether the remaining available space can receive the data chunks sent each time under its chunking strategy. Therefore, it is necessary to ensure that the remaining available space is greater than its chunk size to determine a match; otherwise, there is no match.

[0037] When matching, for example, if the block size is 100k and the remaining available space in the memory pool is greater than 100k, then a continuous 100k memory block is taken from the memory pool as working memory for the upgrade task.

[0038] In some cases, the remaining available space in the memory pool is less than the task space of the software package to be upgraded. In such cases, it is not possible to directly obtain a memory block of the corresponding size. Therefore, when the remaining available space in the memory pool is less than the task space of the software package to be upgraded, the memory difference between the remaining available space in the memory pool and the size of the software package to be upgraded will be calculated.

[0039] Then, based on the memory difference, the corresponding memory space is requested and added to the memory pool. For example, if the calculated memory difference is 50k, then another 50k of memory is requested from the system. This 50k memory increment is added to the memory pool for updating and expansion, and then the corresponding contiguous memory block can be obtained from the memory pool.

[0040] In this embodiment, data reception can only begin after working memory has been acquired. Therefore, after acquiring working memory, status information is sent to the server to synchronize the current working memory status and inform the server that the system is ready to receive upgrade data packets.

[0041] In step S400, the received upgrade data is written into the working memory to perform the upgrade operation, and a confirmation signal is sent to the server to synchronize the upgrade status.

[0042] After acquiring the working memory, the transmitted data will be directly written into it for subsequent upgrade operations. The upgrade operations include verification and parsing. After successful verification and parsing, the write operation can be performed. After the write is completed, the working memory is cleared, and the next data block can be received.

[0043] Therefore, once the current data block has been received, an acknowledgment signal can be sent to the server to synchronize and upgrade the status, informing the server that the current data block has been received and that the next data block can be received.

[0044] Similarly, if the verification and decryption of the data fails, a corresponding signal will be sent to the server to request that the data be resent.

[0045] It is understood that the upgrade steps in this embodiment first confirm the size of the transmitted upgrade package, then obtain memory based on the parsed upgrade package status, and directly obtain a contiguous memory block of the corresponding size from the memory pool, which reduces the waste of memory space and also reduces the latency in terms of steps. This reduces the technical latency problem of "transmitting the full amount of data first and then parsing" in the prior art, and improves the speed and efficiency of data transfer during the upgrade.

[0046] Throughout the upgrade process, as long as the upgrade is not yet complete, the memory blocks obtained from the memory pool will continue to be retained in the task and reused. That is, it is not necessary to repeatedly obtain memory from the memory pool each time the next data block is downloaded, nor is it necessary to release memory back to the memory pool after processing a portion of data. This is because this embodiment first analyzes the download strategy of the upgrade package and knows the size of the data packets downloaded each time. The amount of memory requested is sufficient to support the usage requirements of the entire download and upgrade process, thus greatly reducing the waste of time.

[0047] Step S500: After the upgrade operation is completed, the working memory is released into the memory pool.

[0048] After the upgrade is complete, the working memory can be released from the upgrade task and returned to the memory pool. It's important to understand that "release" here means the working memory is moved from being occupied by the upgrade task to a free state, rather than being directly released back to the system. Therefore, the size of the memory pool will basically remain unchanged, waiting for the next task to be executed before being mobilized again.

[0049] Therefore, this embodiment will also monitor the utilization rate of the additional memory space in the memory pool in real time, and release the memory block when the utilization rate of any additional memory space is lower than a preset value.

[0050] If the memory pool is idle for a long time, most of the memory blocks in it will not be called by tasks, and its utilization rate will be very low. In this case, this part of the memory can be released, and at least the preset basic pool size can be retained.

[0051] For example, each time a memory block is accessed from the memory pool, the number of times it is accessed is recorded. Simultaneously, a timer starts counting from the moment the memory pool is established. Thus, each memory block will have two data points: time and access count. Using these two data points, the access frequency of the memory block per unit of time can be calculated. This access frequency is the utilization rate. By setting a low utilization threshold and calculating the access frequency, it can be determined whether the memory block is in a low utilization state. If the access frequency is less than the low utilization threshold, the memory block is considered low-utilization and needs to be released.

[0052] In addition, the base pool size is also a preset value, such as 100k, to keep the system able to perform basic operations, such as continuing to request new memory, thus ensuring that the system will not run out of memory when necessary.

[0053] If each element in the memory pool is in a high-frequency usage state and its utilization rate is higher than the preset rate, then the current pool size is maintained.

[0054] Furthermore, in the on-board diagnostic system, the method flow of this embodiment is as follows: Figure 2 As shown, when the system or controller initializes, it initializes the DOIP memory pool. The memory pool can be configured based on historical data or manually. When a task is received, the remaining available space is checked. If there is enough space, the required memory is retrieved; otherwise, the required memory is replenished from the system before retrieving the memory block. This memory block is then reused to execute upgrade tasks until the task is completed, at which point the memory is returned. Simultaneously, the utilization rate of memory blocks in the memory pool can be monitored in real time to release long-term, excessive memory blocks and reduce system load.

[0055] The method in this embodiment significantly reduces the number of memory allocation operations throughout the upgrade process by constructing a resident memory pool and adopting a closed-loop management strategy of initial intelligent configuration → continuous block reuse during upgrade → adaptive shrinkage after upgrade. This reduces the total memory allocation latency during the upgrade of large software packages, while improving memory space utilization and suppressing fragmentation, enhancing the system's real-time performance, realizing pipelined processing of the upgrade process, greatly shortening end-to-end writing time, and significantly improving file download efficiency.

[0056] Figure 3 A schematic diagram of an in-vehicle software transfer memory allocation device according to an embodiment of this application is shown. Exemplarily, the in-vehicle software transfer memory allocation device includes: The memory pool allocation module 10 is used to perform memory pool initialization operations after the system starts. The detection module 20 is used to obtain the task space of the software package to be upgraded and check the remaining available space of the memory pool when it receives an upgrade task from the server. The matching module 30 is used to obtain a contiguous memory block of the corresponding size from the memory pool as working memory if the remaining available space of the memory pool matches the task space of the software package to be upgraded. The upgrade module 40 is used to write the received upgrade data into the working memory to perform the upgrade operation and send a confirmation signal to the server to synchronize the upgrade status. The release module 50 is used to release the working memory to the memory pool after the upgrade operation is completed.

[0057] It is understood that the device in this embodiment corresponds to the vehicle software transmission memory allocation method in the above embodiment, and the options in the above embodiment are also applicable to this embodiment, so they will not be described again here.

[0058] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the above-described vehicle software transmission memory allocation method or the above-described vehicle software transmission memory allocation device.

[0059] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0060] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0061] This application also provides a readable storage medium for storing the computer program used in the aforementioned terminal device.

[0062] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, 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 code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in 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 diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, 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.

[0063] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0064] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0065] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for allocating memory for in-vehicle software transmission, characterized in that, include: The memory pool initialization operation is performed after the system starts; When an upgrade task is received from the server, the task space for the software package to be upgraded is obtained, and the remaining available space in the memory pool is checked. If the remaining available space in the memory pool matches the task space of the software package to be upgraded, then a contiguous memory block of the corresponding size is obtained from the memory pool as working memory. The received upgrade data is written into the working memory to perform the upgrade operation, and a confirmation signal is sent to the server to synchronize the upgrade status. After the upgrade operation is completed, the working memory is released into the memory pool.

2. The in-vehicle software transmission memory allocation method according to claim 1, characterized in that, The process of initializing the memory pool after system startup includes: Obtain historical data, and plan and allocate the memory pool size based on the average memory usage, maximum single usage, and volatility in the historical data; Alternatively, the memory pool size can be planned and allocated based on manually entered configuration data.

3. The in-vehicle software transmission memory allocation method according to claim 1, characterized in that, If the remaining available space in the memory pool matches the task space of the software package to be upgraded, then a contiguous memory block of the corresponding size is obtained from the memory pool as working memory, including: If the remaining available space of the memory pool is greater than or equal to the task space, then it is confirmed that the remaining available space of the memory pool matches the task space of the software package to be upgraded. Obtain a contiguous memory block of the same size as the task space from the memory pool and use it as working memory.

4. The in-vehicle software transmission memory allocation method according to claim 1, characterized in that, Also includes: If the remaining available space of the memory pool is less than the task space of the software package to be upgraded, then calculate the memory difference between the remaining available space of the memory pool and the size of the software package to be upgraded. Based on the memory difference, the system requests additional memory space and incorporates it into the memory pool.

5. The in-vehicle software transmission memory allocation method according to claim 4, characterized in that, Also includes: The utilization rate of the additional memory space in the memory pool is monitored in real time. When the utilization rate of any memory block in the additional memory space is lower than a preset value, the memory block is released.

6. The in-vehicle software transmission memory allocation method according to claim 1, characterized in that, When an upgrade task is received, obtaining the task space of the software package to be upgraded includes: Send a request to the server to request the configuration data packet for the software package to be upgraded; Read the task space of the software package to be upgraded from the configuration data package to determine the task space of the software package to be upgraded.

7. The in-vehicle software transmission memory allocation method according to claim 1, characterized in that, After sending a confirmation signal to the server and synchronizing the upgrade status, the process further includes: If the upgrade status is that the upgrade task is not completed, the memory pool is reused repeatedly to repeatedly execute the operation of writing the received upgrade data into the working memory.

8. A vehicle-mounted software transmission memory allocation device, characterized in that, include: The memory pool allocation module is used to perform memory pool initialization operations after the system starts. The detection module is used to obtain the task space of the software package to be upgraded and check the remaining available space of the memory pool when an upgrade task is received from the server. The matching module is used to obtain a contiguous memory block of the corresponding size from the memory pool as working memory if the remaining available space of the memory pool matches the task space of the software package to be upgraded. The upgrade module is used to write the received upgrade data into the working memory to perform the upgrade operation and send a confirmation signal to the server to synchronize the upgrade status. The release module is used to release the working memory to the memory pool after the upgrade operation is completed.

9. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the vehicle software transmission memory allocation method according to any one of claims 1-7.

10. A readable storage medium, characterized in that, It stores a computer program, which, when executed on a processor, implements the vehicle software transmission memory allocation method according to any one of claims 1-7.

Images