A method for sharing storage among multiple ECUs based on virtual files, control units, and products.

Abstract

This application relates to the field of intelligent vehicle technology, proposing a multi-ECU storage sharing method, electronic control unit, and computer program product based on virtual files. The method includes: receiving a file transfer request from an external device, the file transfer request containing the file name, file format, and file size of the file to be transferred; if the file size exceeds the available storage space of the target ECU, then determining a borrowing ECU from among the other ECUs in the vehicle; creating a virtual file according to the file name, file format, and file size, with a portion of the virtual file's storage space located in the target ECU and the remaining portion in the borrowing ECU; receiving the file data of the file to be transferred from the external device and writing the file data into the storage space of the virtual file. This method can solve the problem of ECUs receiving large amounts of data files without requiring cumbersome operations such as disassembling and reassembling the vehicle.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicle technology, and in particular to a method for sharing multi-ECU storage based on virtual files, an electronic control unit, and a computer program product. Background Technology

[0002] With the development of intelligent vehicle technology, modern vehicles can be equipped with up to 100 or more Electronic Control Units (ECUs). An ECU is a small computer capable of executing various control software, possessing independent operating systems, processors, and memory modules. As the brain of the vehicle, the ECU's storage space primarily serves to support control logic and data flow. For example, it is responsible for processing input data from various sensors in real time, providing immediate information support for control decisions; it stores control algorithms and execution logic, directly determining how to respond to sensor signals and drive actuators; and it saves critical data such as fault codes and adaptive learning values, ensuring long-term stable operation and fault traceability of the vehicle, among other things.

[0003] In many cases, it is necessary to transfer files to the ECU via external devices (such as USB flash drives, mobile phones, etc.) to complete various operations, such as transferring firmware files for software upgrades or transferring installation package files for software installation. Because some files are too large, and the ECU's storage space is relatively limited, the problem of the ECU's storage space being unable to receive the files to be transferred frequently arises.

[0004] To address the aforementioned issues, existing technologies typically employ a method of connecting the ECU to an external storage device. This involves connecting external storage devices such as portable hard drives or USB flash drives to the ECU, copying the files to be transferred to the external storage device, and then performing the operation. However, since the ECU is usually installed on the vehicle's internal bus, connecting an external storage device to the ECU requires removing and installing the vehicle, which is cumbersome and problematic. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method for sharing storage among multiple ECUs based on virtual files, an electronic control unit, and a computer program product, which can solve the problem of ECUs receiving large amounts of data files without performing cumbersome operations such as disassembling and reassembling vehicles.

[0006] A first aspect of this application provides a method for sharing storage among multiple ECUs based on virtual files. This method is applied to a target ECU of a vehicle and includes:

[0007] Receive file transfer requests from external devices. The file transfer request includes the file name, file format, and file size of the file to be transferred. If the file size exceeds the available storage space of the target ECU, then a borrowed ECU is determined from the other ECUs in the vehicle. A virtual file is created according to the file name, file format and file size. Part of the storage space of the virtual file is in the target ECU and the other part of the storage space is in the borrowed ECU. It receives file data of a file to be transmitted from an external device and writes the file data into the storage space of a virtual file.

[0008] In the technical solution of this application embodiment, the target ECU of the vehicle receives a file transfer request from an external device. This request includes the file name, file format, and file size of the file to be transferred. If the file size exceeds the available storage space of the target ECU, a borrowing ECU is selected from the other ECUs in the vehicle. Then, a virtual file is created according to the file name, file format, and file size, with a portion of the virtual file's storage space located in the target ECU and the remaining portion in the borrowing ECU. Finally, the file data of the file to be transferred from the external device is received and written to the storage space of the virtual file. Considering that vehicles typically have multiple ECUs, the above process borrows storage space from other ECUs in the vehicle when the target ECU's storage space cannot receive the entire file to be transferred. By creating a virtual file with storage space distributed between the target ECU and the borrowing ECU, and then writing the file data of the file to be transferred into the virtual file's storage space, storage space sharing among multiple ECUs is achieved. This solves the problem of a single ECU being unable to receive large files and eliminates the need for cumbersome operations such as disassembling and reassembling the vehicle. Furthermore, the target ECU can perform various operations on the virtual file as if it were a normal local file.

[0009] In one implementation of this application, creating a virtual file according to file name, file format, and file size includes: Send a borrowing request containing the size of the required storage space to the borrowing ECU to instruct the borrowing ECU to allocate the target storage space according to the required storage space size, and return the address information of the target storage space; After receiving the address information, a virtual file is created according to the file name and file format, and a storage mapping relationship for the virtual file is generated based on the address information. The storage mapping relationship records the correspondence between the logical address of the virtual file and the data storage address.

[0010] In one implementation of this application, writing file data into the storage space of a virtual file includes: The address to be written is determined based on the logical address and storage mapping relationship of the file data to be written; If the address to be written is in the target ECU, then the file data to be written will be written to the storage space corresponding to the address to be written. If the address to be written is in the borrowed ECU, the file data to be written and the address to be written are sent to the borrowed ECU to instruct the borrowed ECU to write the file data to be written to the storage space corresponding to the address to be written.

[0011] In one implementation of this application, after writing the file data into the storage space of the virtual file, the method further includes: When a request to use a virtual file is received, the address to be read is determined based on the logical address and storage mapping relationship of the file data to be read; If the address to be read is located in the target ECU, then the file data to be read is read from the storage space corresponding to the address to be read. If the address to be read is in the borrowed ECU, the data length of the file data to be read and the address to be read are sent to the borrowed ECU to instruct the borrowed ECU to read and return the file data to be read from the storage space corresponding to the address to be read, according to the data length.

[0012] In one implementation of this application, after writing the file data into the storage space of the virtual file, the method further includes: When a request to delete a virtual file is received, the address to be deleted is determined based on the logical address and storage mapping relationship of the file data to be deleted. If the address to be deleted is located in the target ECU, then delete the file data to be deleted from the storage space corresponding to the address to be deleted; If the address to be deleted is in the borrowed ECU, the data length of the file data to be deleted and the address to be deleted are sent to the borrowed ECU to instruct the borrowed ECU to delete the file data to be deleted from the storage space corresponding to the address to be deleted, according to the data length.

[0013] In one implementation of this application, determining the borrowed ECU from the various other ECUs of the vehicle includes: Broadcast an inquiry request containing the amount of memory space to be borrowed to each of the other ECUs, instructing candidate ECUs whose available memory space exceeds the amount of memory space to be borrowed to return condition satisfaction information; Select the borrowed ECU from all candidate ECUs that meet the return conditions.

[0014] In one implementation of this application, selecting a borrowing ECU from all candidate ECUs that return condition-satisfied information includes: From all candidate ECUs, select the candidate ECU with the largest available storage space as the borrowed ECU; or, From all candidate ECUs, select the candidate ECU with the lowest importance to its functional system as the borrowed ECU.

[0015] In one implementation of this application, after receiving a file transfer request from an external device, the method further includes: If the file size does not exceed the available storage space of the target ECU, an empty file is created according to the file name, file format and file size, and the storage space of the empty file is in the target ECU; It receives file data of a file to be transmitted from an external device and writes the file data into the storage space of an empty file.

[0016] A second aspect of this application provides a multi-ECU storage sharing device based on virtual files, which is applied to a target ECU of a vehicle, and the device includes: The file transfer request receiving module is used to receive file transfer requests from external devices. The file transfer request includes the file name, file format, and file size of the file to be transferred. The ECU borrowing determination module is used to determine the borrowing ECU from the various other ECUs in the vehicle if the file size exceeds the available storage space of the target ECU. The virtual file creation module is used to create virtual files according to file name, file format and file size. Part of the storage space of the virtual file is in the target ECU and the other part of the storage space is in the borrowed ECU. The file data writing module is used to receive file data of the file to be transferred from an external device and write the file data into the storage space of the virtual file.

[0017] A third aspect of this application provides an electronic control unit, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the multi-ECU storage sharing method based on virtual files provided in the first aspect of this application.

[0018] A fourth aspect of this application provides a computer program product that, when run on an electronic control unit, causes the electronic control unit to execute the multi-ECU storage sharing method based on virtual files provided in the first aspect of this application.

[0019] The fifth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the multi-ECU storage sharing method based on virtual files provided in the first aspect of this application.

[0020] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of a multi-ECU storage sharing system based on virtual files provided in an embodiment of this application; Figure 2 This is a flowchart of a multi-ECU storage sharing method based on virtual files provided in an embodiment of this application; Figure 3 This is a structural framework diagram of a multi-ECU storage sharing device based on virtual files provided in an embodiment of this application; Figure 4 This is a schematic diagram of an electronic control unit provided in an embodiment of this application. Detailed Implementation

[0022] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail. Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0023] The ECU, acting as the brain of a vehicle, is responsible for controlling various electronic functions and systems. Currently, when transferring files to the ECU via external devices, the ECU's storage space often fails to receive the files. The conventional solution is to connect the ECU to an external storage device, but this requires cumbersome operations such as disassembling and reassembling the vehicle.

[0024] To address the aforementioned problems, this application provides a method for sharing storage space among multiple ECUs based on virtual files, an electronic control unit, and a computer program product. This method enables storage space sharing among multiple ECUs, solves the problem of ECUs receiving large amounts of data files, and eliminates the need for cumbersome operations such as vehicle disassembly and reassembly. For more specific technical details regarding the embodiments of this application, please refer to the various embodiments described below.

[0025] Please see Figure 1 This illustrates a multi-ECU storage sharing system based on virtual files provided in an embodiment of this application. Figure 1The system shown includes external devices and multiple ECUs (Electronic Control Units) installed in the vehicle. The ECU connected to the external devices is called the target ECU, and the other ECUs are called other ECUs. The target ECU and the other ECUs can exchange data via the vehicle bus (e.g., CAN bus). The external devices can be electronic devices with data storage and transmission capabilities, such as USB flash drives or mobile phones, and can establish communication connections with the target ECU via various wired or wireless methods. (About...) Figure 1 For a detailed explanation of the working principle of the system shown, please refer to the method embodiments described below.

[0026] Please see Figure 2 This application illustrates a method for sharing storage among multiple ECUs based on virtual files, applicable to a target ECU in a vehicle. The method includes: 201. Receive a file transfer request from an external device. The file transfer request includes the file name, file format, and file size of the file to be transferred. When it is necessary to transfer files (such as firmware upgrade files or installation package files) to the target ECU of a vehicle, the external device that stores the files to be transferred first sends a file transfer request to the target ECU. This file transfer request contains information such as the file name, file format, and file size of the files to be transferred.

[0027] 202. If the file size exceeds the available storage space of the target ECU, then borrow an ECU from the other ECUs in the vehicle. After receiving a file transfer request from an external device, the target ECU parses the request to obtain information such as the file name, file format, and file size of the file to be transferred, and compares the file size with the target ECU's current available storage space.

[0028] In one implementation of this application, after receiving a file transfer request from an external device, the method further includes: (1) If the file size does not exceed the available storage space of the target ECU, an empty file is created according to the file name, file format and file size, and the storage space of the empty file is in the target ECU; (2) Receive file data of the file to be transmitted from an external device and write the file data into the storage space of an empty file.

[0029] After comparing the file size of the file to be transferred with its own available storage space, if the file size does not exceed the target ECU's available storage space, it means the target ECU can receive the complete file data independently, without needing to borrow storage space from other ECUs in the vehicle. Specifically, the target ECU creates an empty file according to the file name, file format, and file size of the file to be transferred. The storage space for this empty file resides within the target ECU. That is, a new empty file with the same file name and file format as the file to be transferred is created, and corresponding storage space is allocated to this empty file according to the file size of the file to be transferred. Then, the target ECU notifies the external device that the file has been successfully created and data transmission can begin. The external device then transmits the file data of the file to be transferred frame by frame to the target ECU. After receiving the file data, the target ECU writes the file data frame by frame sequentially into the storage space of the empty file. When all file data transmission is complete, it indicates that the file to be transferred has been successfully transferred, and the empty file has been updated to the required file to be transferred. Afterward, the target ECU can use the file to be transferred to perform firmware upgrades or software installations, etc.

[0030] If the file size to be transferred exceeds the available storage space of the target ECU, it means that the target ECU cannot receive the complete file data on its own. In this case, at least one other ECU that can provide storage space needs to be identified from the other ECUs in the vehicle. This ECU is referred to as the borrowing ECU. The specific method for identifying the borrowing ECU is described below.

[0031] In one implementation of this application, determining the borrowed ECU from the various other ECUs of the vehicle includes: (1) Broadcast an inquiry request containing the amount of memory space to be borrowed to each of the other ECUs, so as to instruct the candidate ECUs whose available memory space exceeds the amount of memory space to be borrowed to return condition satisfaction information; (2) Select the borrowed ECU from all candidate ECUs that meet the return conditions.

[0032] When the target ECU detects that the file size of the file to be transferred exceeds the available storage space of the target ECU, the target ECU first determines the amount of storage space to be borrowed based on the difference between the file size and the target ECU's available storage space. For example, assuming the file size is 2GB and the target ECU's available storage space is 1GB, then 1GB of storage space needs to be borrowed. Then, the target ECU broadcasts an inquiry request containing the required storage space size to all other ECUs on the vehicle bus. Upon receiving this inquiry request, any other ECU compares its own available storage space with the required storage space. If its own available storage space exceeds the required storage space, then that other ECU becomes a candidate ECU and returns a condition-satisfied message to the target ECU, which may include the other ECU's available storage space. If the other ECU's available storage space does not exceed the required storage space, then that other ECU does not become a candidate ECU and may either return a condition-unsatisfied message to the target ECU or not return any information. The target ECU will select the desired borrowing ECU from all candidate ECUs that return information indicating that the conditions are met, according to a set method. For example, it can randomly select a borrowing ECU from all candidate ECUs, select the candidate ECU that returns information indicating that the conditions are met the fastest from all candidate ECUs, or select the candidate ECU with the largest available storage space from all candidate ECUs, and so on.

[0033] In one implementation of this application, selecting a borrowing ECU from all candidate ECUs that return condition-satisfied information includes: From all candidate ECUs, select the candidate ECU with the largest available storage space as the borrowed ECU.

[0034] When selecting a borrowed ECU from all candidate ECUs, a preferred approach is to choose the candidate ECU with the largest available storage space. For example, assuming there are candidate ECU1 (1.5GB available storage space), candidate ECU2 (3GB available storage space), and candidate ECU3 (2GB available storage space), then candidate ECU2 is selected as the borrowed ECU. It can be seen that by selecting the candidate ECU with the largest available storage space, the borrowed ECU can avoid having insufficient remaining storage space after borrowing storage space, thus minimizing the impact on the normal operation of the borrowed ECU.

[0035] In another implementation of this application embodiment, selecting a borrowing ECU from all candidate ECUs that return condition-satisfied information includes: From all candidate ECUs, select the candidate ECU with the lowest importance to its functional system as the borrowed ECU.

[0036] When selecting a borrowed ECU from all candidate ECUs, another preferred approach is to choose the candidate ECU with the lowest importance level in its respective functional system as the borrowed ECU. Considering that the borrowed ECU needs to provide storage space to the target ECU, this process inevitably involves a significant amount of data interaction with the target ECU, thus consuming the borrowed ECU's performance resources and impacting its normal operation. Therefore, prioritizing the selection of the candidate ECU with the lowest importance level in its respective functional system reduces the severity of potential risks arising from its impact. In practice, the target ECU can pre-store the importance levels of various functional systems within the vehicle. For example, the importance levels of systems related to vehicle safety, such as the powertrain and steering systems, can be set higher, while the importance levels of systems related to user comfort, such as the air conditioning, seating, and entertainment systems, can be set lower. Assuming the candidate ECUs include candidate ECU1 (belonging to the powertrain system), candidate ECU2 (belonging to the steering system), and candidate ECU3 (belonging to the entertainment system), candidate ECU3 is selected as the borrowed ECU. This will not affect the vehicle's powertrain and steering systems, ensuring the safety of vehicle operation. The only possible impact is a reduction in the smoothness of the entertainment system's operation.

[0037] 203. Create a virtual file according to the file name, file format and file size. Part of the storage space of the virtual file is in the target ECU and the other part of the storage space is in the borrowed ECU. After identifying the borrowing ECU from the other ECUs in the vehicle, the target ECU borrows the necessary storage space from it and creates a virtual file based on the filename, format, and size of the file to be transferred. A portion of the storage space for this virtual file resides in the target ECU, while the remaining portion is allocated to the borrowing ECU. Specifically, the target ECU creates a virtual file with the same name and format as the file to be transferred, and divides its storage space into two parts based on the file size and the target ECU's available storage space. The target ECU allocates a portion of the storage space for this virtual file itself and simultaneously instructs the borrowing ECU to allocate the remaining portion. For details on this process, please refer to the following section.

[0038] In one implementation of this application, creating a virtual file according to file name, file format, and file size includes: (1) Send a borrowing request containing the size of the required storage space to the borrowing ECU to instruct the borrowing ECU to allocate the target storage space according to the required storage space size, and return the address information of the target storage space; (2) After receiving the address information, create a virtual file according to the file name and file format, and generate the storage mapping relationship of the virtual file according to the address information. The storage mapping relationship records the correspondence between the data logical address and the data storage address of the virtual file.

[0039] Specifically, the target ECU sends a request to the borrowing ECU containing the size of the required storage space. Upon receiving the request, the borrowing ECU internally allocates a storage space according to the required size, designated as the target storage space, and returns address information, including the starting address of the target storage space, to the target ECU. This indicates successful storage space borrowing. After receiving the address information returned by the borrowing ECU, the target ECU begins creating a virtual file: creating a virtual file with the same name and format as the file to be transferred, and generating a storage mapping relationship for this virtual file based on the received address information. This storage mapping relationship records the correspondence between the logical data address and the data storage address of the virtual file. For example, assuming the file size to be transferred is 2GB, the logical address of the file data is 0-0x7FFFFFFF, a total of 2GB bytes. Its storage is divided into two parts. The first part, 1GB of data 0-0x3FFFFFFF, is stored in the storage space of address 1-address 2 of the target ECU. The second part, 1GB of data 0x40000000-0x7FFFFFFF, is stored in the storage space of address 3-address 4 of the borrowing ECU. The above storage mapping relationship records the correspondence between the data logical address "0-0x3FFFFFFF" and the data storage address "address 1-address 2 of the target ECU", as well as the correspondence between the data logical address "0x40000000-0x7FFFFFFFF" and the data storage address "address 3-address 4 of the borrowing ECU".

[0040] 204. Receive file data of the file to be transmitted from an external device and write the file data into the storage space of the virtual file.

[0041] After the virtual file is created, the target ECU notifies the external device that the file has been successfully created and data transfer can begin. The external device then transmits the file data to be transferred frame by frame to the target ECU. Upon receiving the file data, the target ECU writes the file data sequentially frame by frame into the virtual file's storage space. It's important to note that since part of the virtual file's storage space resides with the target ECU and the other part with the borrowed ECU, when writing the file data frame by frame into the virtual file's storage space, the target ECU needs to look up the corresponding storage address from the aforementioned storage mapping relationship based on the logical address of the current frame's file data. If the storage address is with the target ECU, the current frame's file data is directly written to that storage address. If the storage address is with the borrowed ECU, both the storage address and the current frame's file data need to be sent to the borrowed ECU, which then writes the current frame's file data to that storage address. Once all file data transfers are complete, it indicates that the file to be transferred has been successfully transferred, and the virtual file has been updated to the required file. Afterward, the target ECU can perform various operations on the virtual file as if it were a normal local file, such as using the virtual file to perform firmware upgrades or software installations.

[0042] Next, the specific implementation methods for data writing, data reading, and data deletion operations on the virtual file will be described in turn.

[0043] In one implementation of this application, writing file data into the storage space of a virtual file includes: (1) Determine the address to be written based on the logical address and storage mapping relationship of the file data to be written; (2) If the address to be written is in the target ECU, then the file data to be written is written to the storage space corresponding to the address to be written; (3) If the address to be written is in the borrowed ECU, the file data to be written and the address to be written are sent to the borrowed ECU to instruct the borrowed ECU to write the file data to be written into the storage space corresponding to the address to be written.

[0044] When writing file data frame by frame sequentially into the storage space of a virtual file, the target ECU first determines the address to be written based on the logical address of the file data to be written and the aforementioned storage mapping relationship. For example, assuming the file data to be written is data frame 1, the corresponding storage address can be found from the aforementioned storage mapping relationship based on the logical address of data frame 1, and recorded as the address to be written. If the address to be written is within the target ECU, the target ECU directly writes the file data to be written into the storage space corresponding to the address to be written; if the address to be written is within the borrowing ECU, the target ECU needs to send both the file data to be written and the address to be written to the borrowing ECU, which then writes the file data to be written into the storage space corresponding to the address to be written. For example, assuming the address to be written for data frame 1 is address 1 of the target ECU, the target ECU directly writes data frame 1 into address 1 of the target ECU; assuming the address to be written for data frame 1 is address 3 of the borrowing ECU, the target ECU sends both data frame 1 and address 3 of the borrowing ECU to the borrowing ECU, which then writes data frame 1 into address 3 of the borrowing ECU, and so on. Furthermore, if more than one ECU is borrowed, the target ECU needs to send data to each of the borrowing ECUs separately. For example, assuming the address to be written for data frame 2 is address 4 of borrowing ECU 1, the target ECU sends both data frame 2 and address 4 of borrowing ECU 1 to borrowing ECU 1, and borrowing ECU 1 writes data frame 2 to address 4 of borrowing ECU 1; assuming the address to be written for data frame 3 is address 6 of borrowing ECU 2, the target ECU sends both data frame 3 and address 6 of borrowing ECU 2 to borrowing ECU 2, and borrowing ECU 2 writes data frame 3 to address 6 of borrowing ECU 2, and so on.

[0045] In one implementation of this application, after writing the file data into the storage space of the virtual file, the method further includes: (1) When a request to use a virtual file is received, the address to be read is determined according to the logical address and storage mapping relationship of the file data to be read; (2) If the address to be read is in the target ECU, then read the file data to be read from the storage space corresponding to the address to be read; (3) If the address to be read is in the borrowed ECU, the data length of the file data to be read and the address to be read are sent to the borrowed ECU to instruct the borrowed ECU to read and return the file data to be read from the storage space corresponding to the address to be read, according to the data length.

[0046] After all the file data of the file to be transferred is written to the storage space of the virtual file, the target ECU can use the virtual file to perform operations such as firmware upgrades or software installations. Specifically, when the target ECU receives a request to use the virtual file, it performs normal file access operations. When acquiring the file data of the virtual file frame by frame, it first determines the address to be read based on the logical address of the file data to be read and the aforementioned storage mapping relationship. For example, assuming the file data to be read is data frame 1, the corresponding storage address can be found from the aforementioned storage mapping relationship based on the logical address of data frame 1, and recorded as the address to be read. If the address to be read is in the target ECU, the target ECU can directly read the file data to be read from the storage space corresponding to the address to be read; if the address to be read is in the borrowing ECU, the target ECU needs to send both the data length of the file data to be read and the address to be read to the borrowing ECU, which then reads the file data to be read from the storage space corresponding to the address to be read according to the data length and returns the file data to be read to the target ECU. For example, assuming the address to be read for data frame 1 is address 1 of the target ECU, the target ECU can directly read data frame 1 through address 1. If the address to be read for data frame 1 is address 3 of the borrowing ECU, the target ECU sends both the data length of data frame 1 and the address 3 of the borrowing ECU to the borrowing ECU. The borrowing ECU then reads the corresponding data length of data frame 1 from address 3 and returns the read data frame 1 to the target ECU, and so on. With this setup, the target ECU can use virtual files as conveniently as local files.

[0047] In one implementation of this application, after writing the file data into the storage space of the virtual file, the method further includes: (1) When a request to delete a virtual file is received, the address to be deleted is determined based on the logical address and storage mapping relationship of the file data to be deleted; (2) If the address to be deleted is in the target ECU, then delete the file data to be deleted from the storage space corresponding to the address to be deleted; (3) If the address to be deleted is in the borrowed ECU, the data length of the file data to be deleted and the address to be deleted are sent to the borrowed ECU to instruct the borrowed ECU to delete the file data to be deleted from the storage space corresponding to the address to be deleted according to the data length.

[0048] After writing all the file data of the file to be transferred into the storage space of the virtual file, if it is necessary to delete the virtual file, the target ECU can also complete the frame-by-frame deletion operation of the file data according to the above storage mapping relationship. Specifically, when the target ECU receives a request to delete a virtual file, it first determines the address to be deleted based on the logical address of the file data to be deleted and the above storage mapping relationship. For example, assuming the file data to be deleted is data frame 1, the corresponding storage address can be found in the above storage mapping relationship based on the logical address of data frame 1, and recorded as the address to be deleted. If the address to be deleted is in the target ECU, the target ECU can directly delete the file data to be deleted from the storage space corresponding to the address to be deleted; if the address to be deleted is in the borrowing ECU, the target ECU needs to send the data length of the file data to be deleted and the address to be deleted to the borrowing ECU, and the borrowing ECU will delete the file data to be deleted from the storage space corresponding to the address to be deleted according to the data length. For example, assuming the address to be deleted for data frame 1 is address 1 of the target ECU, the target ECU can directly delete data frame 1 from its local address 1. If the address to be deleted for data frame 1 is address 3 of the borrowing ECU, the target ECU sends both the data length of data frame 1 and the address 3 of the borrowing ECU to the borrowing ECU. The borrowing ECU then deletes data frame 1 of the corresponding length from address 3 and sets the corresponding storage space at address 3 as free storage space, and so on. With this setup, deleting virtual files is as convenient for the target ECU as deleting local files.

[0049] In the technical solution of this application embodiment, the target ECU of the vehicle receives a file transfer request from an external device. This request includes the file name, file format, and file size of the file to be transferred. If the file size exceeds the available storage space of the target ECU, a borrowing ECU is selected from the other ECUs in the vehicle. Then, a virtual file is created according to the file name, file format, and file size, with a portion of the virtual file's storage space located in the target ECU and the remaining portion in the borrowing ECU. Finally, the file data of the file to be transferred from the external device is received and written to the storage space of the virtual file. Considering that vehicles typically have multiple ECUs, the above process borrows storage space from other ECUs in the vehicle when the target ECU's storage space cannot receive the entire file to be transferred. By creating a virtual file with storage space distributed between the target ECU and the borrowing ECU, and then writing the file data of the file to be transferred into the virtual file's storage space, storage space sharing among multiple ECUs is achieved. This solves the problem of a single ECU being unable to receive large files and eliminates the need for cumbersome operations such as disassembling and reassembling the vehicle. Furthermore, the target ECU can perform various operations on the virtual file as if it were a normal local file.

[0050] In summary, the technical solution of this application embodiment can make full use of the idle storage space in each ECU of the vehicle and realize the effect of multiple ECUs sharing storage space based on virtual files. In this way, each ECU can operate virtual files with a large amount of data normally. It can accurately obtain the required file data simply by using the storage mapping relationship, thus successfully solving the problem that a single ECU cannot handle large data files and has high practical application value.

[0051] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0052] The above mainly describes a multi-ECU storage sharing method based on virtual files. The following will describe a multi-ECU storage sharing device based on virtual files.

[0053] Please see Figure 3 This application illustrates a multi-ECU storage sharing device based on virtual files, which is applied to a target ECU of a vehicle. The device includes: The transmission request receiving module 301 is used to receive file transmission requests from external devices. The file transmission request includes the file name, file format and file size of the file to be transmitted. The ECU borrowing determination module 302 is used to determine the borrowing ECU from the various other ECUs in the vehicle if the file size exceeds the available storage space of the target ECU. The virtual file creation module 303 is used to create virtual files according to file name, file format and file size. Part of the storage space of the virtual file is in the target ECU and the other part of the storage space is in the borrowed ECU. The file data writing module 304 is used to receive file data of a file to be transmitted from an external device and write the file data into the storage space of a virtual file.

[0054] In one implementation of this application, the virtual file creation module includes: The borrowing request sending unit is used to send a borrowing request containing the size of the required borrowed storage space to the borrowing ECU, so as to instruct the borrowing ECU to allocate the target storage space according to the required borrowed storage space size, and return the address information of the target storage space; The virtual file creation unit is used to create a virtual file according to the file name and file format after receiving the address information, and to generate a storage mapping relationship for the virtual file based on the address information. The storage mapping relationship records the correspondence between the data logical address and the data storage address of the virtual file.

[0055] In one implementation of this application, the file data writing module includes: The write address determination unit is used to determine the write address based on the logical address and storage mapping relationship of the file data to be written; The first data writing unit is used to write the file data to be written to the storage space corresponding to the address to be written if the address to be written is in the target ECU. The second data writing unit is used to send the file data to be written and the address to be written to the borrowing ECU if the address to be written is in the borrowing ECU, so as to instruct the borrowing ECU to write the file data to be written to the storage space corresponding to the address to be written.

[0056] In one implementation of this application, the multi-ECU storage sharing device based on virtual files further includes: The read address determination module is used to determine the read address based on the logical address and storage mapping relationship of the file data to be read when a request to use a virtual file is received; The first data reading module is used to read the file data to be read from the storage space corresponding to the address to be read if the address to be read is in the target ECU. The first data reading module is used to send the data length of the file data to be read and the address to be read to the borrowing ECU if the address to be read is in the borrowing ECU, so as to instruct the borrowing ECU to read and return the file data to be read from the storage space corresponding to the address to be read according to the data length.

[0057] In one implementation of this application, the multi-ECU storage sharing device based on virtual files further includes: The deletion address determination module is used to determine the deletion address based on the logical address and storage mapping relationship of the file data to be deleted when a request to delete a virtual file is received. The first data deletion module is used to delete the file data to be deleted from the storage space corresponding to the address to be deleted if the address to be deleted is in the target ECU. The first data deletion module is used to send the data length of the file data to be deleted and the address to be deleted to the borrowing ECU if the address to be deleted is in the borrowing ECU, so as to instruct the borrowing ECU to delete the file data to be deleted from the storage space corresponding to the address to be deleted according to the data length.

[0058] In one implementation of this application, the ECU determination module includes: The query request broadcasting unit is used to broadcast a query request containing the amount of memory space to be borrowed to each other ECU, so as to instruct the candidate ECUs whose available memory space exceeds the amount of memory space to be borrowed to return condition satisfaction information; The borrowed ECU selection unit is used to select a borrowed ECU from all candidate ECUs that meet the returned condition information.

[0059] In one implementation of this application, the ECU selection unit includes: The first ECU selection subunit is used to select the candidate ECU with the largest available storage space from all candidate ECUs as the borrowed ECU; The second ECU selection subunit is used to select the candidate ECU with the lowest importance of its functional system from all candidate ECUs, and use it as the borrowed ECU.

[0060] In one implementation of this application, the multi-ECU storage sharing device based on virtual files further includes: The empty file creation module is used to create an empty file according to the file name, file format and file size if the file size does not exceed the available storage space of the target ECU. The storage space of the empty file is in the target ECU. The empty file writing module is used to receive file data of a file to be transmitted from an external device and write the file data into the storage space of an empty file.

[0061] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the multi-ECU storage sharing method based on virtual files as described in any of the above embodiments.

[0062] This application also provides a computer program product that, when running on an electronic control unit, causes the electronic control unit to execute a multi-ECU storage sharing method based on virtual files as described in any of the above embodiments.

[0063] Figure 4 This is a schematic diagram of an electronic control unit provided in an embodiment of this application. Figure 4 As shown, the electronic control unit 4 in this embodiment includes a processor 40, a memory 41, and a computer program 42 stored in the memory 41 and executable on the processor 40. When the processor 40 executes the computer program 42, it implements the steps in the embodiments of the various multi-ECU storage sharing methods based on virtual files described above, for example... Figure 2Steps 201 to 204 are shown. Alternatively, when the processor 40 executes the computer program 42, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 3 The functions of modules 301 to 304 are shown.

[0064] The computer program 42 can be divided into one or more modules / units, which are stored in the memory 41 and executed by the processor 40 to complete this application. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 42 in the electronic control unit 4.

[0065] The processor 40 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0066] The memory 41 can be an internal storage unit of the electronic control unit 4, such as a hard disk or memory of the electronic control unit 4. The memory 41 can also be an external storage device of the electronic control unit 4, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic control unit 4. Furthermore, the memory 41 can include both internal storage units and external storage devices of the electronic control unit 4. The memory 41 is used to store the computer program and other programs and data required by the electronic control unit. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0067] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0068] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0069] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0070] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0071] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0072] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0073] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0074] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0075] The above-described 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, and should all be included within the protection scope of this application.

Claims

1. A method for sharing a multi-ECU storage based on a virtual file, characterized by, A target ECU applied to a vehicle, the method comprising: receiving a file transmission request of an external device, the file transmission request containing a file name, a file format and a file size of a file to be transmitted; if the file size exceeds a size of available storage space of the target ECU, determining a borrowed ECU from each other ECU of the vehicle; creating a virtual file according to the file name, the file format and the file size, a part of storage space of the virtual file being in the target ECU and the other part being in the borrowed ECU; receiving file data of the file to be transmitted transmitted by the external device and writing the file data into the storage space of the virtual file.

2. The method of claim 1, wherein, The creating of the virtual file according to the file name, the file format and the file size comprises: sending a borrowing request containing a size of storage space to be borrowed to the borrowed ECU to instruct the borrowed ECU to allocate a target storage space according to the size of storage space to be borrowed and return address information of the target storage space; after receiving the address information, creating the virtual file according to the file name and the file format and generating a storage mapping relationship of the virtual file according to the address information, the storage mapping relationship recording a corresponding relationship between a data logical address and a data storage address of the virtual file.

3. The method of claim 2, wherein, The writing of the file data into the storage space of the virtual file comprises: determining a to-be-written address according to a logical address of the file data to be written and the storage mapping relationship; if the to-be-written address is in the target ECU, writing the file data to be written into a storage space corresponding to the to-be-written address; if the to-be-written address is in the borrowed ECU, sending the file data to be written and the to-be-written address to the borrowed ECU to instruct the borrowed ECU to write the file data to be written into a storage space corresponding to the to-be-written address.

4. The method of claim 2, wherein, After the writing of the file data into the storage space of the virtual file, the method further comprises: when receiving a request to use the virtual file, determining a to-be-read address according to a logical address of the file data to be read and the storage mapping relationship; if the to-be-read address is in the target ECU, reading the file data to be read from a storage space corresponding to the to-be-read address; if the to-be-read address is in the borrowed ECU, sending a data length of the file data to be read and the to-be-read address to the borrowed ECU to instruct the borrowed ECU to read and return the file data to be read according to the data length from a storage space corresponding to the to-be-read address.

5. The method of claim 2, wherein, After the writing of the file data into the storage space of the virtual file, the method further comprises: when receiving a request to delete the virtual file, determining a to-be-deleted address according to a logical address of the file data to be deleted and the storage mapping relationship; if the address to be deleted is in the target ECU, deleting the file data to be deleted from the storage space corresponding to the address to be deleted; if the address to be deleted is in the borrowed ECU, sending the data length of the file data to be deleted and the address to be deleted to the borrowed ECU, to instruct the borrowed ECU to delete the file data to be deleted from the storage space corresponding to the address to be deleted according to the data length.

6. The method of claim 1, wherein, The determining of the borrowed ECU from each other ECU of the vehicle comprises: broadcasting an inquiry request containing a required borrowed storage space size to each other ECU, to instruct the candidate ECUs whose available storage space size exceeds the required borrowed storage space size to return condition satisfaction information; selecting the borrowed ECU from all the candidate ECUs returning the condition satisfaction information.

7. The method of claim 6, wherein, The selecting of the borrowed ECU from all the candidate ECUs returning the condition satisfaction information comprises: selecting the candidate ECU with the largest available storage space size as the borrowed ECU from all the candidate ECUs; or, selecting the candidate ECU with the lowest importance of the functional system as the borrowed ECU from all the candidate ECUs.

8. The method according to any one of claims 1 to 7, characterized in that, After the receiving of the file transmission request of the external device, the method further comprises: if the file size does not exceed the available storage space size of the target ECU, creating an empty file according to the file name, the file format and the file size, and the storage space of the empty file is in the target ECU; receiving the file data of the file to be transmitted transmitted by the external device, and writing the file data into the storage space of the empty file.

9. An electronic control unit comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor implements the virtual file-based multi-ECU storage sharing method according to any one of claims 1-8 when executing the computer program.

10. A computer program product, characterised in that, The computer program product, when running on the electronic control unit, causes the electronic control unit to execute the virtual file-based multi-ECU storage sharing method according to any one of claims 1-8.

Images