A data loading iteration method for a multi-core secure vehicle platform

Abstract

The application relates to a data loading iteration method for a multi-core safety vehicle-mounted platform, and the method comprises the following steps: S1, a pointer and an image file chain table are made according to multiple types and version numbers of image files in CPUs in any MPB, the pointer points to the image file chain table, and the CPUs execute the image files in sequence according to the image file chain table; S2, when the CPU executing the current image file needs to rollback the image file, a historical version number image file is found according to the image file chain table and is executed; and S3, when the CPU executing the current image file needs to update the image file, a future version number image file is found according to the image file chain table and is executed. Through the pointer and the image file chain table, the loading, rollback and updating of the image file are completed, the pointer respectively points to the image file of the current version and the historical version, and when data is replaced, the data replacement can be completed by only changing the pointing direction.

Description

Technical Field

[0001] This invention relates to the field of data loading iteration technology, and in particular to a data loading iteration method for a multi-core secure vehicle platform. Background Technology

[0002] With the accelerating pace of intelligent and digital transformation in rail transit, modern train control systems increasingly rely on high-performance onboard computing platforms. Multi-core processors, with their strong parallel processing capabilities and high resource utilization, have become the core hardware platform for next-generation train network control, condition monitoring, fault diagnosis, and other critical systems. However, multi-core platforms face challenges such as low image loading efficiency, large storage redundancy, and complex secure boot mechanisms during system startup, software updates, and fault recovery. Traditional image management solutions struggle to meet the high availability, rapid recovery, and resource optimization requirements of multi-core platforms. Especially in the harsh operating environment of trains, where storage media reliability is limited, image integrity verification and fault tolerance mechanisms become critical challenges for stable system operation.

[0003] Chinese patent application CN118377498A discloses a method, system, and medium for creating and loading image files and multi-core processors. The method includes: S1, allocating resources according to the core number of a digital signal processor to generate an executable file; S2, deploying an image creation tool based on the executable file to initialize a linking tool; creating a single multi-core image file on the server side using the linking tool; S3, providing a download address for the single multi-core image file on the server side for download by the user; the single multi-core image file on the server side includes a multi-core loading table for deploying and loading multi-core applications on the user side; this patent does not disclose the use of pointers and linked lists for the iterative loading process of the image file.

[0004] Therefore, providing an image loading and storage solution optimized for the characteristics of multi-core automotive platforms is an urgent problem to be solved. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art and provide a data loading iteration method for a multi-core secure vehicle platform.

[0006] The objective of this invention can be achieved through the following technical solutions:

[0007] According to one aspect of the present invention, a data loading iteration method for a multi-core secure vehicle platform is provided, comprising an external storage device and multiple MPBs, each MPB comprising multiple CPUs, each CPU comprising a flash storage device, wherein both the external storage device and the flash storage device store image files of various types and version numbers, the method specifically comprising:

[0008] S1. Create pointers and image file linked lists based on image files of various types and version numbers in the CPU of any MPB. The pointers point to the image file linked lists, and the CPU executes the image files sequentially according to the image file linked lists.

[0009] S2. If the CPU needs to roll back the image file when executing the current image file, it finds the image file with the historical version number according to the image file linked list and executes it.

[0010] S3. If the CPU needs to update the image file when executing the current image file, it finds the image file with the future version number according to the image file linked list and executes it.

[0011] As a preferred technical solution, the pointer includes a head pointer, a last pointer, and a next pointer. The image file linked list includes a current image file linked list and a historical image file linked list. The current image file linked list points to the current version number address, and the historical image file linked list points to the historical version number address. The head pointer of the linked list points to the current image file linked list. Image files of the same type and current version number are linked to the historical image file linked list through the last pointer, and image files of different types and current version numbers are linked sequentially through the next pointer.

[0012] As a preferred technical solution, step S1 specifically includes:

[0013] S11. For multiple CPUs under the same MPB, encode the addresses of the image files of the same type and their corresponding historical version numbers under the same CPU in sequence, and form a linked list of image files.

[0014] S111. After any CPU is powered on, an arbitrary image file is obtained from the CPU's flash memory;

[0015] S112, and load the obtained image file into the CPU's memory, compare the CRC of the image file in memory with the CRC of the image file in flash memory. If the comparison results are consistent, execute the image file program and traverse the image file linked list.

[0016] S113. Repeat S112 until the image file of the CPU is executed.

[0017] S114. Repeat S111-S113 to complete the loading of CPU image files for all MPBs.

[0018] As a preferred technical solution, step S2 specifically includes:

[0019] S21. If any current image file in any CPU of any MPB wants to revert to an image file with a specified version number, then the MPB checks whether its own historical version number is the specified version number.

[0020] S22. If the version numbers are inconsistent, a query signal is sent to other MPBs and external storage to check if there is an image file with the specified version number to complete the rollback.

[0021] As a preferred technical solution, step S22 specifically includes:

[0022] S221. If the external storage does not have an image file with a specified version number, the external storage sends a data transfer request to the MPB to transfer the image file with the specified version number to the external storage.

[0023] S222. If any other MPB has an image file with the specified version number, a data transfer request is sent to it, and the MPB accepts the image file with the specified version number.

[0024] S223. If the MPB receives multiple data transmission requests, it shall select any other MPB to reply to and accept the image file with the specified version number.

[0025] S224. If the MPB does not receive a data transfer request from another MPB and the external storage has an image file with a specified version number, then the MPB sends its data transfer request to the external storage, and the external storage transfers the image file with the specified version number.

[0026] As a preferred technical solution, after reverting to a specified version number, the last and next pointers of the current image file list and the historical image file list of the same type are swapped.

[0027] As a preferred technical solution, step S3 specifically includes:

[0028] S31. The external storage device communicates with all MPBs via SWB broadcast to query whether there is an image file with a future version number in the MPB;

[0029] S32. If all types of image files for the CPU in any MPB are future version numbers, then they remain unchanged.

[0030] S33. If all types of image files in any MPB CPU are not future version numbers, then the external memory sends the image file of the previous version number to the MPB and the MPB reverts to that version.

[0031] As a preferred technical solution, step S33 specifically includes:

[0032] S331. If the external storage does not have an image file with the previous version number, then the image file with the previous version number sent from the MPB is received via SWB and stored.

[0033] As a preferred technical solution, after the version update is completed, the last and next pointers of all current image file linked lists and historical image file linked lists are swapped.

[0034] As a preferred technical solution, the MPB is divided into one master MPB and multiple slave MPBs. After all image files are loaded, each MPB sends the CRC of its own image file to other MPBs for verification. After mutual verification is successful, the master MPB runs the program.

[0035] Compared with the prior art, the present invention has the following beneficial effects:

[0036] 1. This invention uses pointers and a linked list of image files to load, roll back, and update image files. The pointers point to the current version and the historical version of the image file, respectively. When data is updated, only the pointing direction needs to be changed to complete the data update.

[0037] 2. The image file of the present invention can be stored in the flash of the MPB and external memory, without wasting the flash space of the chip, while preserving as many historical versions as possible, which facilitates the reproduction of fault scenarios and various environmental tests.

[0038] 3. After loading the image into memory, the MPB of this invention performs a CRC check to ensure data integrity. At the same time, each MPB will check the CRC of all images to ensure data consistency.

[0039] 4. The MPB of the present invention can store multiple image files in its flash memory at the same time. If version rollback is required, and the historical images are all the same, it is only necessary to change the offset address of the image to be read. Attached Figure Description

[0040] Figure 1 This is a schematic diagram illustrating the data loading process of the present invention;

[0041] Figure 2 This is a schematic diagram illustrating the data rollback process of the present invention;

[0042] Figure 3 This is a schematic diagram illustrating the data update process of the present invention;

[0043] Figure 4 This is a schematic diagram of the architecture of the MPB of the present invention. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0045] Example 1

[0046] A data loading iteration method for a multi-core secure vehicle platform includes external storage and multiple MPBs, each MPB including multiple CPUs, and each CPU including flash storage. The method is characterized in that both the external storage and the flash storage store image files of various types and version numbers.

[0047] S1. Create pointers and image file linked lists based on image files of various types and version numbers in the CPU of any MPB. The pointers point to the image file linked lists, and the CPU executes the image files sequentially according to the image file linked lists.

[0048] S2. If the CPU needs to roll back the image file when executing the current image file, it finds the image file with the historical version number according to the image file linked list and executes it.

[0049] S3. If the CPU needs to update the image file when executing the current image file, it finds the image file with the future version number according to the image file linked list and executes it.

[0050] In this embodiment, the image file of the vehicle platform is stored in two locations: one is the flash memory within the CPU of the board, and the other is external memory. Each board includes multiple CPUs, and each CPU includes multiple cores. Multiple versions of the image file for each core can exist simultaneously, but the maximum number needs to be set according to the actual flash or disk size, and these addresses are all stored in fixed addresses. Specifically, a single board includes three CPUs, and each CPU includes three cores. The architecture of a single MBP is as follows... Figure 4 As shown. In addition to storing the image file in flash memory, the Cyclic Redundancy Check (CRC) code of the image file and the size of the image file should also be written into it.

[0051] The onboard platform's boards communicate with each other via a switching board and connect to external devices. After the CPU powers on, it only reads and loads the image file from the CPU's flash memory; the image file stored in external memory only serves a version management function.

[0052] The pointers include a head pointer, a last pointer, and a next pointer. The image file linked list includes a current image file linked list and a historical image file linked list. The current image file linked list points to the current version number address, and the historical image file linked list points to the historical version number address. The head pointer of the linked list points to the current image file linked list. Image files of the same type and current version number are linked to the historical image file linked list through the last pointer, and image files of different types and current version numbers are linked sequentially through the next pointer.

[0053] In this embodiment, the image file linked list includes two sub-lists: the current image file linked list and the historical image file linked list. The pointers include a head pointer, a last pointer, and a next pointer. Image files of different types and different version numbers are linked through pointers.

[0054] Step S1 specifically includes:

[0055] S11. For multiple CPUs under the same MPB, encode the addresses of the image files of the same type and their corresponding historical version numbers under the same CPU in sequence, and form a linked list of image files.

[0056] S111. After any CPU is powered on, an arbitrary image file is obtained from the CPU's flash memory;

[0057] S112, and load the obtained image file into the CPU's memory, compare the CRC of the image file in memory with the CRC of the image file in flash memory. If the comparison results are consistent, execute the image file program and traverse the image file linked list.

[0058] S113. Repeat S112 until the image file of the CPU is executed.

[0059] S114. Repeat S111-S113 to complete the loading of CPU image files for all MPBs.

[0060] In this embodiment, the loading process of the image file is as follows:

[0061] Taking the main computing board MPB as an example, in the current automotive platform, the MPB CPU has three cores: A53, R500, and R510. The A53 core needs to load three types of image files: A53_OS, A53_BSW, and A53_ASW. Similarly, the R500 and R510 cores also need to load three types of images (R50_OS, R50_BSW, R50_ASW and R51_OS, R51_BSW, R51_ASW).

[0062] The current vehicle platform has two MPBs. The flash memory in the CPU of MPB1 already contains image files with version numbers V1 and V3, while the flash memory in the CPU of MPB1 contains image files with version numbers V2 and V3.

[0063] The format is stored at address OFFSET_LINK_START. Figure 1 The three pointers shown are the image file linked lists for the three cores: LINK_A53, LINK_R50, and LINK_R51. They record the offset addresses at which various types of image files should be loaded in each core. All MPB V3 version (current version) image files are stored at address OFFSET_1, while the other version (historical version) is stored at address OFFSET_2.

[0064] Taking LINK_A53 as an example, there are two sub-tables: the current image file linked list and the historical image file linked list, which point to the address of the current version number and the address of the historical version number, respectively; the last method links the current version and historical version of OS, BSW and ASW respectively, and the next method links the current version of OS, BSW and ASW in sequence to achieve sequential reading.

[0065] After the system powers on, the bootloader reads the head node of the linked list pointed to by the pointer at OFFSET_LINK_START. From the recorded offset addresses of each OS (OFFSET_A53_OS_1, OFFSET_R50_OS_1, and OFFSET_R51_OS_1), it loads the OS image file into memory. It then calculates the CRC of the loaded image and compares it with the CRC stored in flash memory. If they match, execution of the OS program begins. Next, it traverses the linked list (pointed to by next node), loading the other two types of images into memory from their recorded offset addresses, performing CRC checks, and then starting execution. The process is the same for the R50 and R51 cores.

[0066] At this point, all platform images have been loaded. The MPB sends the CRC of all its image files to other MPBs. After mutual verification, the vehicle platform MPB begins to execute the main computing program.

[0067] Step S2 specifically includes:

[0068] S21. If any current image file in any CPU of any MPB wants to revert to an image file with a specified version number, then the MPB checks whether its own historical version number is the specified version number.

[0069] S22. If the version numbers are inconsistent, a query signal is sent to other MPBs and external storage to check if there is an image file with the specified version number to complete the rollback.

[0070] Step S22 specifically includes:

[0071] S221. If the external storage does not have an image file with a specified version number, the external storage sends a data transfer request to the MPB to transfer the image file with the specified version number to the external storage.

[0072] S222. If any other MPB has an image file with the specified version number, a data transfer request is sent to it, and the MPB accepts the image file with the specified version number.

[0073] S223. If the MPB receives multiple data transmission requests, it shall select any other MPB to reply to and accept the image file with the specified version number.

[0074] S224. If the MPB does not receive a data transfer request from another MPB and the external storage has an image file with a specified version number, then the MPB sends its data transfer request to the external storage, and the external storage transfers the image file with the specified version number.

[0075] After reverting to the specified version number, swap the last and next pointers of the current image file list and the historical image file list of the same type.

[0076] In this embodiment, if the MPB's A53_BSW image file needs to be rolled back to V1, the MPB first checks if the historical version number of A53_BSW (the node pointed to by last) in its own linked list is V1. If not, it first checks if other MPBs have a V1 version image file, and simultaneously sends this MPB's historical version number to the peripheral device. If the external device does not have this version, the peripheral device needs to request the MPB to send the image data; if other MPBs have the image of this version, they initiate a data transmission request. The MPB receives multiple transmission requests and selects only one reply to indicate that transmission can proceed. If no data transmission request is received, the MPB requests the peripheral device to send V1 image data for updating. And at this time, the historical version is as follows... Figure 1 As shown, if the data is stored at OFFSET_A53_BSW_2, then the updated data should also be written to this address.

[0077] After the update is complete, the next and last nodes pointed to by BSW in the linked list need to be swapped, such as... Figure 2 As shown. If the vehicle platform is restarted at this time, the image loaded into memory will become A53_BSW_V1, while the loading of other images will remain unchanged.

[0078] Step S3 specifically includes:

[0079] S31. The external storage device communicates with all MPBs via SWB broadcast to query whether there is an image file with a future version number in the MPB;

[0080] S32. If all types of image files for the CPU in any MPB are future version numbers, then they remain unchanged.

[0081] S33. If all types of image files in any MPB CPU are not future version numbers, then the external memory sends the image file of the previous version number to the MPB and the MPB reverts to that version.

[0082] Step S33 specifically includes:

[0083] S331. If the external storage does not have an image file with the previous version number, then the image file with the previous version number sent from the MPB is received via SWB and stored.

[0084] After the version update is completed, swap the last and next pointers of all current image file linked lists and historical image file linked lists.

[0085] In this embodiment, the MPB is divided into one master MPB and multiple slave MPBs. After all image files are loaded, each MPB sends the CRC of its own image file to other MPBs for verification. After mutual verification is successful, the master MPB runs the program.

[0086] If version iteration is required (i.e., writing images of all A53 cores for version V4), the external device first broadcasts a scan via SWB. If all A53 images currently stored in the MPB are version V4, they remain unchanged and do not participate in the current update. Otherwise, it replies with the previous version number, A53_BSW. If the external device does not contain this historical version, it requests the MPB to send the image data to the external storage via SWB. After receiving all historical versions, the external device begins transmitting V4. The MPB writes V4 to the address where the historical versions were stored.

[0087] like Figure 3 As shown, it is necessary to first traverse the linked list, write the V4 image into the address of the previous version image, update the offset address of the head node of the linked list recorded in OFFSET_LINK_START LINK_A53, and swap the linked list nodes pointed to by the next and last pointers of all nodes. Then restart the vehicle platform, and the image loaded into memory by traversing the linked list becomes V4.

[0088] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A data loading iteration method for a multi-core secure vehicle platform, comprising external storage and multiple MPBs, each MPB comprising multiple CPUs, and each CPU comprising flash storage, characterized in that, Both the external storage and the flash storage store image files of various types and version numbers. The method specifically includes: S1. Create pointers and image file linked lists based on image files of various types and version numbers in the CPU of any MPB. The pointers point to the image file linked lists, and the CPU executes the image files sequentially according to the image file linked lists. S2. If the CPU needs to roll back the image file when executing the current image file, it finds the image file with the historical version number according to the image file linked list and executes it. S3. If the CPU needs to update the image file when executing the current image file, it finds the image file with the future version number according to the image file linked list and executes it. The pointers include a head pointer, a last pointer, and a next pointer. The image file linked list includes a current image file linked list and a historical image file linked list. The current image file linked list points to the current version number address, and the historical image file linked list points to the historical version number address. The head pointer of the linked list points to the current image file linked list. Image files of the same type and current version number are linked to the historical image file linked list through the last pointer. Image files of different types and current version numbers are linked sequentially through the next pointer. Step S1 specifically includes: S11. For multiple CPUs under the same MPB, encode the addresses of the image files of the same type and their corresponding historical version numbers under the same CPU in sequence, and form a linked list of image files. S111. After any CPU is powered on, an arbitrary image file is obtained from the CPU's flash memory; S112, and load the obtained image file into the CPU's memory, compare the CRC of the image file in memory with the CRC of the image file in flash memory, if the comparison results are consistent, execute the image file and traverse the image file linked list. S113. Repeat S112 until the image file of the CPU is executed. S114. Repeat S111-S113 to complete the loading of CPU image files for all MPBs.

2. The data loading iteration method for a multi-core secure vehicle platform according to claim 1, characterized in that, Step S2 specifically includes: S21. If any current image file in any CPU of any MPB wants to revert to an image file with a specified version number, then the MPB checks whether its own historical version number is the specified version number. S22. If the version numbers are inconsistent, a query signal is sent to other MPBs and external storage to check if there is an image file with the specified version number to complete the rollback.

3. The data loading iteration method for a multi-core secure vehicle platform according to claim 2, characterized in that, Step S22 specifically includes: S221. If the external storage does not have an image file with a specified version number, the external storage sends a data transfer request to the MPB to transfer the image file with the specified version number to the external storage. S222. If any other MPB has an image file with the specified version number, a data transfer request is sent to it, and the MPB accepts the image file with the specified version number. S223. If the MPB receives multiple data transmission requests, it shall select any other MPB to reply to and accept the image file with the specified version number. S224. If the MPB does not receive a data transfer request from another MPB and the external storage has an image file with a specified version number, then the MPB sends its data transfer request to the external storage, and the external storage transfers the image file with the specified version number.

4. The data loading iteration method for a multi-core secure vehicle platform according to claim 3, characterized in that, After reverting to the specified version number, swap the last and next pointers of the current image file list and the historical image file list of the same type.

5. The data loading iteration method for a multi-core secure vehicle platform according to claim 1, characterized in that, Step S3 specifically includes: S31. The external storage device communicates with all MPBs via SWB broadcast to query whether there is an image file with a future version number in the MPB; S32. If all types of image files for the CPU in any MPB are future version numbers, then they remain unchanged. S33. If all types of image files in any MPB CPU are not future version numbers, then the external memory sends the image file of the previous version number to the MPB and the MPB reverts to that version.

6. The data loading iteration method for a multi-core secure vehicle platform according to claim 5, characterized in that, Step S33 specifically includes: S331. If the external storage does not have an image file with the previous version number, then the image file with the previous version number sent from the MPB is received via SWB and stored.

7. The data loading iteration method for a multi-core secure vehicle platform according to claim 6, characterized in that, After the version update is completed, swap the last and next pointers of all current image file linked lists and historical image file linked lists.

8. The data loading iteration method for a multi-core secure vehicle platform according to claim 1, characterized in that, The MPB is divided into one master MPB and multiple slave MPBs. After all image files are loaded, each MPB sends the CRC of its own image file to other MPBs for verification. After mutual verification is successful, the master MPB runs the program.

Images