Differential data loading method capable of loading software aircraft parts

Abstract

The invention relates to a software-loadable aircraft component differential data loading method, which comprises the following steps that a first data file and a second data file are subjected to block processing to generate data blocks and corresponding position sequences, and the first data file and the second data file comprise old data files and new data files; performing coding calculation on the data blocks, and establishing a data block index; comparing the coding values of the new and old data blocks based on a sliding window algorithm, determining a data difference according to a comparison result, and generating a difference file which comprises an instruction set representing data addition, modification or deletion; the difference file is packaged into a difference LSAP of a difference loadable aircraft component; transmitting the differential LSAP to a target system; and analyzing and verifying the differential LSAP in the target system, updating data according to the instruction set, and generating a new data file.

Description

Technical Field

[0001] This invention relates to the field of avionics system data maintenance technology, specifically to a differential data loading method for loadable software aircraft components in airborne systems, and more particularly to a method for generating and applying differential packets through data segmentation, hash indexing, and sliding window comparison to achieve efficient and reliable firmware loading. Background Technology

[0002] Data loading is a core technology for enabling remote updates and maintenance of airborne software. Currently, the industry commonly uses the Loadable Software Aircraft Component (LSAP) whole-package loading method. However, this method has significant drawbacks in practical applications: First, due to the need to transmit the complete software package, the data volume is enormous, which can easily lead to transmission failure or low success rate in environments with limited airborne equipment bandwidth and unstable network conditions; second, the transmission and verification process of large files is time-consuming, seriously affecting maintenance efficiency and increasing the operation time window; third, whole-package loading requires a full erase and write operation of the airborne non-volatile memory (NVM). Even if only a small amount of data in the file changes, the entire storage area needs to be repeatedly flushed, which not only unnecessarily consumes the limited erase and write life of the memory but also wastes user bandwidth and overall system resources.

[0003] To optimize the above process, existing technologies have proposed several solutions. For example, some solutions use resource allocation algorithms and modular architectures to allocate and load LSAP, but their design focuses on system adaptability and task scheduling, failing to effectively address the core issues of high hardware resource consumption and low transmission efficiency during loading. Another solution uses partitioned compression for firmware over-the-air loading, reducing transmission size through compression; however, this method is essentially still a whole-packet transmission, failing to fundamentally improve transmission time and lacking effective support for incremental loading of multiple versions. Furthermore, some solutions focus on improving the security of the update process through redundancy backups and manual command triggering, but their approach emphasizes fault tolerance in the operational process and does not optimize the data generation, transmission, and storage mechanisms themselves, thus offering no substantial contribution to improving transmission efficiency or reducing resource consumption.

[0004] Therefore, there is an urgent need in this field for an innovative data loading method that can overcome the shortcomings of existing whole-packet loading and the aforementioned technical solutions, and significantly improve loading efficiency, save transmission resources and extend hardware lifespan while ensuring aviation-grade safety and reliability. Summary of the Invention

[0005] This invention addresses the aforementioned problems and aims to provide a differential data loading method for loadable software aircraft components, overcoming the efficiency and resource limitations of existing whole-package loading methods. Specifically, it aims to reduce the amount of data transmitted during the loading process of loadable software aircraft components by transmitting differential packets containing only version differences, thereby improving the transmission success rate and speed in constrained network environments. It also avoids repeated writing to unmodified data areas in onboard memory, reducing overall system bandwidth costs and conserving the erase / write lifespan of non-volatile memory.

[0006] This invention provides a method for loading differential data of a loadable software aircraft component, comprising the following steps: The first LSAP packet and the second LSAP packet are parsed respectively to obtain a first data file and a second data file. The first LSAP packet is a newly acquired software package that has not yet been loaded into the loadable software aircraft component, and the second LSAP packet is a software package that is currently loaded into the loadable software aircraft component. The first data file and the second data file are respectively divided into blocks to generate a first data block set and a second data block set with position sequences; Assign an index to each first data block in the first data block set and each second data block in the second data block set; Based on the index and using a sliding window algorithm, the first data block set and the second data block set are compared to generate a difference file. The difference file is a set of instructions for converting the second data file into the first data file, generated based on the differences between the first data block set and the second data block set. Generate a differential LSAP packet based on the differential file; and The second data file is updated to the first data file based on the differential LSAP packet.

[0007] In another embodiment of the method according to the present invention, the block-based processing of the first data file and the second data file includes: dividing the first data file and the second data file into data blocks of fixed size; when the length of the first data file and the second data file is not an integer multiple of the block size, the last block is padded with zero values, wherein the first data file is a new data file and the second data file is an old data file. Preferably, the encoding calculation is implemented using a hash function. Preferably, the encoding calculation is implemented using at least two hash functions to reduce the risk of hash collisions.

[0008] In another embodiment of the method according to the present invention, the comparison of the encoded values ​​of the first data block set and the second data block set based on the sliding window algorithm includes: using a sliding window of fixed size to move in units of length on the sequence of the first data block set, the unit length including one or more data blocks; calculating the composite hash value of the window sequence; and searching for a match in the index of the second data block set.

[0009] In another embodiment of the method according to the present invention, if the match is successful, a copy operation instruction is generated based on the position sequence of the matched second data block and the position sequence of the current sliding window; If the match fails, a byte-level comparison is performed between the first data block in the sliding window and the data block in the corresponding position area of ​​the second data block set, and a new operation instruction or a deletion operation instruction is generated based on the comparison result. The sliding window is slid across the first data block at preset steps to perform matching until the entire set of the first data blocks has been traversed.

[0010] In another embodiment of the method according to the present invention, the operation types in the instruction set include: copy operation, add operation, and delete operation; the copy operation records the source offset, target offset, and length; the add operation records the target offset and data block content; and the delete operation records the source offset and length.

[0011] In another embodiment of the method according to the present invention, encapsulating the differential file into a differential LSAP includes: Generate a header file containing a checksum and control information, wherein the control information includes at least one of component identifier, device location information, and file format version. Encapsulate the header file with a differential data file and a support file to form a differential LSAP.

[0012] Preferably, transmitting the differential LSAP to the target system includes transmitting the differential LSAP to the target location via an avionics bus or network protocol.

[0013] In another embodiment of the method according to the invention, the resolution and verification of differential LSAP in the target system includes: The received differential LSAP is unpacked, and the checksum and control information in the header file are verified. After verification, the original data block and the differential data block are merged in the dynamic volatile memory to generate a new file; After verifying that the new file is running normally, the update results are written to non-volatile memory to complete the loading.

[0014] Preferably, the method further includes a resume function: When the differential LSAP transmission is interrupted, the current download progress information is persistently stored in non-volatile memory, and the transmission continues from the interruption point when the transmission resumes.

[0015] This invention fundamentally eliminates redundant data transmission by generating and transmitting differential packets containing only version-specific changes, rather than complete software packages. Based on data compression theory, the sliding window algorithm and file difference extraction improve the effective compression ratio, thereby significantly increasing transmission speed and loading success rate under constrained networks. Regarding resource consumption, this method combines fine-grained management at the data block level, using hash indexes to accurately locate and only flush specific storage blocks that have undergone changes. Given the physical characteristics of non-volatile memory, its lifespan is directly related to the number of erase / write cycles; therefore, avoiding invalid operations on unmodified blocks effectively extends memory lifespan and saves communication bandwidth. Attached Figure Description

[0016] The following figures are only used to provide a further understanding of the present invention and form part of this specification. They are used to explain the principles of the present invention and do not constitute a limitation thereof.

[0017] In the diagram: Figure 1 A flowchart of a method for loading differential data of a loadable software aircraft component according to an embodiment of the present invention; Figure 2 A schematic diagram of the structure of the new data block and the old data block according to an embodiment of the present invention; and Figure 3 This is a flowchart of differential LSAP update according to an embodiment of the present invention. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present application.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, for example, that a process, method, system, product, or apparatus comprising a series of steps or units must precede those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] In this application, the terms "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" indicate directions or positional relationships based on the orientations or positional relationships shown in the accompanying drawings. These terms are primarily for the purpose of better describing this application and its embodiments, and are not intended to limit the indicated devices, elements, or components to having a specific orientation, or to be constructed and operated in a specific orientation.

[0021] Furthermore, in addition to indicating location or positional relationship, some of the aforementioned terms may also have other meanings. For example, the term "above" may also be used in certain circumstances to indicate a certain dependency or connection. Those skilled in the art can understand the specific meaning of these terms in this application based on the specific circumstances.

[0022] Furthermore, the terms "installation," "setting," "arrangement," "equipped with," "connection," "linking," and "socketing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral structure; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediary medium; or they can refer to the internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. The relevant terms are explained below.

[0023] "LSAP parsing" refers to the process of parsing LSAP. The .LUH file verifies the files in LSAP, extracts the data file and supporting file names, obtains the data file and supporting files, and provides the basic data file for file processing.

[0024] "Differential localization and generation" utilizes a sliding window algorithm. A fixed-size window, preferably a variable-size window, slides forward in a consistent direction (left and right) throughout the entire data block, finding data blocks that meet specific conditions. When the hash values ​​of the old and new data blocks are the same, it means the old data block is identical to the new data block, and this data block does not need to be updated. When the hash values ​​of the new and old data blocks are inconsistent, a more detailed comparison of the specific data in the old and new data blocks is conducted to identify the differences, including data additions, modifications, or deletions. For three different types of data operations, add, modify, and delete data blocks are generated, along with their offsets in the old and new data files, ultimately generating the differential LSAP.

[0025] "Differential LSAP packaging" refers to the use of checksum generation to create a checksum, along with necessary control information such as part number and device location information. The .LUH header file, along with the differential data file and supporting files, is packaged into a differential LSAP.

[0026] "Differential LSAP transmission" refers to the transmission of differential LSAP to the target airborne system based on the specific bus or network, different devices and protocols.

[0027] "Differential LSAP update" refers to the process by which the target airborne system, upon receiving a differential LSAP, parses and verifies it. If successful, it processes modified, newly added, and deleted data blocks, merges the original data with the differential data, generates a new file, and completes the data flushing.

[0028] It should be noted that, where there is no conflict, the embodiments and features described in this application can be combined with each other. To make the solution of the present invention clearer, the present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0029] like Figure 1 As shown, the present invention provides a method for loading differential data of a loadable software aircraft component (LSAP), specifically including the following steps: STEP 1: Generate a differential update package between the old data file and the new data file; STEP 1.1: Data block preprocessing; The new and old data and supporting files are divided into blocks to generate data blocks and their corresponding position sequences.

[0030] During the data partitioning phase, both old and new data are divided into fixed-size blocks to ensure consistency in granularity and processing efficiency for subsequent comparisons. For example... Figure 2As shown, D_O represents the old data file, and D_N represents the new data file. Both the old and new data files are divided into multiple data blocks. Specifically, a predefined block size is chosen, such as 4KB or 8KB, which is determined based on the data type and application scenario. The block size should be consistent to facilitate alignment and comparison. For the old data, it is divided into a continuous sequence of data blocks, forming a list of old data blocks, denoted as OLD_DATA_BLOCKS = [OLD_DATA1, OLD_DATA2, ..., OLD_DATA...]. N [N], where N is the total number of old data blocks; for new data, it is also divided into a list of new data blocks, denoted as NEW_DATA_BLOCKS = [NEW_DATA1, NEW_DATA2, ..., NEW_DATABLOCKS]. M M represents the total number of new data blocks. If the data length is not an integer multiple of the block size, the last block is padded with zeros to ensure that all data blocks are of uniform size. This generates a list of new data blocks and a list of old data blocks, providing a basis for subsequent encoding calculations and matching of new and old data blocks.

[0031] STEP 1.2: Encoding calculation and mapping table construction of new and old data blocks; Encoding calculations are performed on the new data blocks obtained in the previous step and the old data blocks. Encoding calculations are typically performed using a hash function, such as the SHA-256 algorithm. A unique encoded value, or hash value, is generated for each data block. For the old data blocks, the OLD_DATA value is calculated for each data block. i Hash value H_OLD i A hash value mapping table, OLD_HASH_MAP, is constructed. This mapping table uses hash values ​​as keys and lists of corresponding old data block indices as values. Specifically, for each data block's corresponding hash value H, OLD_HASH_MAP[H] = [index1, index2, ...], where indexj is the position index of the old data block with hash value H in OLD_BLOCKS. This mapping table supports fast lookups and provides the foundation for subsequent sliding window matching. It is important to note that the encoding calculations for new and old data blocks, i.e., the hash value calculations, are independent of each other; therefore, parallel computation can be used to improve computational efficiency.

[0032] STEP 1.3: Matching data blocks in a sliding window; This step employs a sliding window algorithm with a fixed window size to perform matching operations on the new data block sequence. The window size k is defined as a fixed number of consecutive data blocks, where k is a positive integer and k≥1, for example, k=1, 2, or 3. The sliding window moves across the new data block list NEW_DATA_BLOCKS in steps of 1 data block, starting from index 0 and moving one data block position at a time until the window covers all possible data block sequences.

[0033] Specifically, for each window position i, where i ranges from 0 to Nk, the following sub-steps are performed.

[0034] Window hash calculation, extract the new data block sequence WINDOW_NEW=[B_NEW] i B_NEW i+1 , ..., B_NEW i+k-1 If k=1, the hash value of a single data block, calculated during the encoding of new and old data blocks and the construction of the mapping table, is used directly. If k>1, the composite hash value of the window sequence is calculated, for example, by concatenating the hash values ​​of each block and then calculating the SHA-256 hash, or by using a rolling hash algorithm.

[0035] Perform a matching search, looking for the window hash value in OLD_HASH_MAP. If a matching hash value exists, iterate through the corresponding old data block index list, and for each candidate old window position j, verify the old data block sequence [B_OLD]. j B_OLD j+1 , ..., B_OLD j+k-1 The check checks if the data is completely identical to `WINDOW_NEW`. Verification is performed by comparing data content byte-by-byte. If verification is successful, matching information is recorded, including the source offset (j × block size), target offset (i × block size), and length (k × block size), and these old data block indices are marked as matched. Then, the window slides to position i+k (skipping the matching window). If no match is found, the window slides to position i+1. The "source offset" refers to the distance from the beginning of the old data file to the starting byte of a specific piece of data, used to precisely locate a segment of data in the old file. The "target offset" refers to the starting byte position where a segment of data should be placed in the new data file, used to precisely specify the location where data should be written when building the new file.

[0036] Identify common sequences in new and old data blocks by using sliding window matching.

[0037] STEP 1.4: Difference Analysis and Operation Generation; Based on the matching results of the sliding window data blocks, perform difference analysis on the unmatched data blocks and generate update type operations. Specifically: Copy operation: For a sequence of matching data blocks, a copy operation is generated, recording the source offset, target offset, and length.

[0038] Add operation: Traverse the list of new data blocks. For data blocks that did not match during the sliding window data block matching process, generate a new operation, recording the target offset and data block content. If a data block partially matches (i.e., the content is different), it is considered a new operation.

[0039] Deletion operation: Traverse the list of old data blocks. For data blocks that were not marked as matched during the sliding window data block matching process, generate a deletion operation and record the source offset and length.

[0040] After the above operations are generated, sequence optimization is performed to ensure that all data block changes are captured, such as merging adjacent copy or add operations to reduce the number of operations.

[0041] STEP 1.5: Differential LSAP Generation and Output; The instruction set generated during the difference analysis process is serialized into support files and data files. These support files and data files are then encapsulated into an update package, also known as a difference package or differential LSAP. The support file records the block size, old data size, new data size, and number of operations. Specifically, the support file can be a custom file, either a standalone file or part of a header file. The specific content and format of the LUH header file are shown in Table 1. The data file sequentially stores detailed information for each operation, including operation type, offset, length, etc. The support file also records CRC and other information for verification purposes.

[0042] Table 1 .LUH header file content and format

[0043] STEP 2: Differential LSAP transmission; Differential LSAP is transmitted to the target system, i.e., the target airborne system, via appropriate devices and according to the corresponding bus or network loading protocol. Aviation bus or network loading protocols include ARINC615A, ARINC826, or ARINC615. For example, ARINC615A might be used for AFDX networks, while ARINC826 or ARINC615 might be used for CAN or 429 buses.

[0044] STEP 3: Differential LSAP Update; The target system parses and verifies the differential LSAP, completing the loading and updating of the differential LSAP data. Upon receiving the differential LSAP, the target airborne system first performs unpacking. Then it will... The checksum and other control information in the .LUH file are verified to ensure that the received data is correct, tamper-proof, and conforms to the expected operation type (such as addition, modification, or deletion). For modified data blocks, the target airborne system updates the existing data blocks according to the indicated location and method; for added data blocks, the newly added content is inserted into the appropriate position; for deleted data blocks, if there are data items that need to be removed, the target airborne system is responsible for cleaning up the corresponding data. Based on the old data, a new file data is generated according to the differential file.

[0045] Additionally, it's important to note that after receiving the differential LSAP, the airborne system stores it in designated non-volatile memory before parsing and verifying it. After successful parsing and verification, it processes modified, added, and deleted data blocks, merging the original and differential data blocks in dynamic volatile memory to generate a new file. Once the software is running normally in dynamic volatile memory, it uses the updated results to load the old LSAP and update it to the new LSAP. For example... Figure 3 As shown, when the software encounters an anomaly while running in dynamic volatile memory, i.e. the LSAP verification is incorrect, the old LSAP is not updated, the old LSAP is rolled back to maintain the original configuration, the loading process is terminated without loading.

[0046] During differential loading, dynamic volatile memory (such as RAM) and non-volatile memory (such as Flash) work closely together to achieve efficient and reliable firmware updates. The entire process begins with the differential packet download phase, where differential data obtained from the server is first stored in RAM, utilizing its high-speed read / write capabilities for rapid data reception and temporary storage. Subsequently, the system reads the complete firmware of the current version from Flash and loads it into the working area of ​​RAM, preparing it for subsequent processing along with the differential packet. In the core merging phase, the differential restoration algorithm runs at full speed in RAM, comparing and reconstructing the differential packet with the current version through frequent data access and calculations, ultimately generating a complete new firmware file. After merging, the system writes the generated new firmware to Flash for persistent storage, typically employing a strategy of writing to a temporary area first, verifying it, and then officially replacing it to ensure data storage reliability. Finally, the system quickly verifies the integrity of the new firmware in RAM by calculating a hash value and comparing it with the expected value. If verification is successful, the device restarts and loads and runs the new version from Flash.

[0047] The updated differential LSAP according to embodiments of the present invention also supports breakpoint resumption. In the differential loading scenario with breakpoint resumption, the cooperation between dynamic volatile memory and non-volatile memory becomes closer and more intelligent. When the loading process is unexpectedly interrupted due to network interruption or device restart, the system immediately transfers the current download progress information, including the amount of data received, checksum, and breakpoint position, from RAM to a special area of ​​Flash for persistent storage. This mechanism ensures that the loading progress is not lost even in the extreme case of a complete power outage. When resuming loading, the system first reads the saved breakpoint information from Flash, re-establishes the connection with the server, and requests to continue transmission from the breakpoint position. Newly received differential packet data is also first buffered in RAM. For partially downloaded data, the system will choose to retain it in Flash or reload it into RAM for subsequent processing, while ensuring data continuity through an incremental checksum mechanism. During the merging process, the system adopts a more cautious strategy, periodically saving key processing states to Flash to prevent unexpected interruptions during the merging process. Throughout the breakpoint resume process, non-volatile memory plays a crucial role in maintaining progress, backing up data, and restoring state, while dynamic volatile memory continues to leverage its high-speed processing advantage. Together, they construct a loading system with fault recovery capabilities, significantly improving the success rate of differential loading and the user experience in unreliable network environments.

[0048] The implementation of this invention is not limited to the embodiments described above, and can be adjusted and optimized according to different design requirements and usage environments. The scope of protection of this invention should be determined by the content of the claims, and not limited to the embodiments described above. Although this invention has been described through specific embodiments, any modifications, changes, and combinations made by those skilled in the art to the various embodiments and implementation methods of this invention without departing from the spirit of this invention should be within the scope of protection of this invention.

Claims

1. A data loading method for a loadable software aircraft component, characterized in that, Includes the following steps: The first LSAP packet and the second LSAP packet are parsed respectively to obtain a first data file and a second data file. The first LSAP packet is a newly acquired software package that has not yet been loaded into the loadable software aircraft component, and the second LSAP packet is a software package that is currently loaded into the loadable software aircraft component. The first data file and the second data file are respectively divided into blocks to generate a first data block set and a second data block set with position sequences; Assign an index to each first data block in the first data block set and each second data block in the second data block set; Based on the index and using a sliding window algorithm, the first data block set and the second data block set are compared to generate a difference file. The difference file is a set of instructions for converting the second data file into the first data file, generated based on the differences between the first data block set and the second data block set. Generate a differential LSAP packet based on the differential file; and The second data file is updated to the first data file based on the differential LSAP packet.

2. The method according to claim 1, characterized in that, The block-splitting process for the first data file and the second data file includes: dividing the first data file and the second data file into data blocks of fixed size; when the length of the first data file and the second data file is not an integer multiple of the block size, the last block is filled with zero values; wherein the first data file is a new data file and the second data file is an old data file.

3. The method according to claim 1, characterized in that, The encoding calculation is implemented using a hash function.

4. The method according to claim 3, characterized in that, The encoding calculation is implemented using at least two hash functions.

5. The method according to claim 1, characterized in that, The step of comparing the encoded values ​​of the first data block set and the second data block set based on the sliding window algorithm includes: using a sliding window of fixed size to move in units of length on the sequence of the first data block set, wherein the unit length includes one or more data blocks; calculating the composite hash value of the window sequence; and searching for a match in the index of the second data block set.

6. The method according to claim 5, characterized in that, If a match is successful, a copy operation instruction is generated based on the position sequence of the matched second data block and the position sequence of the current sliding window. If the match fails, a byte-level comparison is performed between the first data block in the sliding window and the data block in the corresponding position area of ​​the second data block set, and a new operation instruction or a deletion operation instruction is generated based on the comparison result. The sliding window is slid across the first data block at preset steps to perform matching until the entire set of the first data blocks has been traversed.

7. The method according to claim 1, characterized in that, The operation types in the instruction set include: copy operation, add operation, and delete operation; the copy operation records the source offset, target offset, and length; the add operation records the target offset and data block content; and the delete operation records the source offset and length.

8. The method according to claim 1, characterized in that, Encapsulating the differential file into a differential LSAP includes: Generate a header file containing a checksum and control information, wherein the control information includes at least one of component identifier, device location information, and file format version. Encapsulate the header file with a differential data file and a support file to form a differential LSAP.

9. The method according to claim 1, characterized in that, Transmitting the differential LSAP to the target system includes transmitting the differential LSAP to the target location via an avionics bus or network protocol.

10. The method according to claim 1, characterized in that, The resolution and verification of differential LSAP in the target system includes: The received differential LSAP is unpacked, and the checksum and control information in the header file are verified. After verification, the original data block and the differential data block are merged in the dynamic volatile memory to generate a new file; After verifying that the new file is running normally, the update results are written to non-volatile memory to complete the loading.

11. The method according to claim 1, characterized in that, The method also includes a resume function: When the differential LSAP transmission is interrupted, the current download progress information is stored in non-volatile memory, and the transmission continues from the interruption point when the transmission resumes.

Images