A method for verifying aircraft data storage based on post-write readback comparison

Abstract

This invention relates to a method for verifying aircraft data storage based on post-write readback comparison, belonging to the field of aircraft data processing technology. Specifically, it includes: acquiring flight data to generate raw data frames; signing the raw data frames to form signed data units; writing the data units to the main memory while simultaneously reading all data from the same physical address to form readback data units; comparing the readback data units with the written data units byte-by-byte; if they are completely identical, the write operation is deemed physically successful; if any byte is inconsistent or the readback fails, the write operation is deemed physically unsuccessful; when a write operation is deemed physically unsuccessful, the main controller immediately executes a preset fault-tolerance strategy. This invention does not rely on any status signals returned by the storage device and enforces closed-loop verification at the physical layer for each write operation, ensuring that each data write is physically authentic, complete, and verifiable.

Description

Technical Field

[0001] This invention relates to a method for verifying aircraft data storage based on post-write readback comparison, belonging to the field of aircraft data processing technology. Background Technology

[0002] In the field of avionics, aircraft need to continuously collect and store critical flight data such as inertial measurement unit (IMU), GPS positioning, and attitude angles onto SD card storage media during operation. Under actual aircraft operating conditions, SD cards face harsh environments such as vibration and shock, drastic temperature changes (-40℃ to 85℃), power supply voltage fluctuations, and electromagnetic interference. During the data writing process, anomalies such as bit flips, incomplete data writing, or write address offsets may occur, resulting in inconsistencies between the stored data and the original data.

[0003] Currently, existing data comparison mechanisms mainly rely on device status information returned by the SD card controller. However, if the data recording system relies excessively on device status information (such as capacity declarations in the CSD register) returned by the SD card controller for storage decisions, it may lead to the system misjudging available space, exceeding actual storage capacity during long-term continuous flight data recording, resulting in data loss, and thus affecting the integrity of key evidence in flight accident investigations.

[0004] Furthermore, device information returned by the SD card controller (such as capacity and sector size fields in the CSD register) may be unreliable on some abnormal storage media. If the storage management logic directly relies on such information for storage space calculation and allocation, it will lead to misjudgment of storage space and errors in data write decisions. Traditional write-back comparison methods do not rely on the accuracy of device status information; storage anomalies can be detected at the data layer through actual data write and readback verification. Summary of the Invention

[0005] To address the technical problems existing in the prior art, this invention provides a method for verifying aircraft data storage based on post-write readback comparison. This method does not rely on any status signals returned by the storage device and enforces physical-level closed-loop verification for each write operation, ensuring that each data write is authentic, complete, and verifiable at the physical level.

[0006] To achieve the above objectives, the technical solution adopted in this invention is a method for verifying aircraft data storage based on post-write readback comparison, comprising a main controller, a main memory, and an aircraft data acquisition module installed on the aircraft. The main controller is connected to the aircraft data acquisition module and the main memory, and the method is implemented according to the following steps: S1. The aircraft data acquisition module collects flight data at a fixed sampling rate and generates raw data frames. S2. Calculate the HMAC-SHA256 signature after serializing the original data frame, and append the signature to the end of the data frame to form a signed data unit. S3. The main controller forcibly writes a signed data unit to a target physical address in the main memory; at the same time, the main controller reads all the data of the data unit from the same physical address back to the main controller's volatile memory, forming a readback data unit; S4. The main controller compares the read data unit with the written data unit byte by byte. If every byte is completely consistent, the write operation is determined to be physically successful. If any byte is inconsistent or the read operation fails, the write operation is determined to be physically failed. S5. When it is determined that the physical write is successful, continue to repeat steps S1-S4; when it is determined that the physical write fails, the main controller immediately executes the preset fault tolerance strategy.

[0007] Preferably, the fault tolerance strategy includes: rewriting the data units that need to be written to a backup memory, the backup memory being connected to the main controller, and the physical connection and communication link between the backup memory and the main controller operating independently of the physical connection and communication link between the main memory and the main controller.

[0008] Preferably, the main memory is a SD card connected to the main controller via an SDMMC interface, and the backup memory is a non-volatile memory such as Flash, EEPROM, FRAM, and NVRAM built into the main controller or an external storage medium connected via a backup interface.

[0009] Preferably, step S3 further includes a data buffering step, which is as follows: S11. The data unit to be written is first stored in a first-in-first-out (FIFO) buffer queue; S12. After the storage verification task retrieves data units from the queue asynchronously, it executes the closed-loop verification process from S1 to S3 in sequence. The depth requirement of the FIFO buffer queue is estimated using the following formula: Queue_Depth ≥ T_store × F_sample, Where T_store is the average time taken for a single write and verification, including the complete process of steps S3-S5, and F_sample is the data sampling rate; When the FIFO buffer queue depth exceeds a preset threshold, the main controller automatically initiates a degradation strategy, temporarily skipping the verification task to perform raw writing or increasing the priority of the verification task, so as to ensure that the storage task can still be completed under transient pressure.

[0010] Preferably, the main controller is also connected to an anomaly detection module, which is used to detect whether the aircraft is experiencing or is about to experience a high overload impact through sensors. When it is determined that a high overload impact is being encountered or about to be encountered, the main controller sets the flag bit with a hardware instruction and stores the flag bit in the shared memory of the main controller; When performing write and verification tasks, the main controller first checks whether the flag bit is valid. If the flag bit is valid, it immediately executes the fault tolerance strategy and records the fault log until the flag bit is cleared.

[0011] Preferably, step S4 further includes a link recovery step, which is as follows: when the main controller detects that the number of comparison failures exceeds a preset link failure threshold, the main controller attempts to restore normal communication with the main memory through initialization and reset. If communication is successfully restored, the main controller will continue to write subsequent data units into the main memory and write back the data temporarily stored in the backup memory to the main memory. If communication cannot be restored after multiple attempts, the main controller will continue to write data to the backup storage and report an alarm signal to notify maintenance personnel to intervene.

[0012] Compared with the prior art, the present invention has the following technical effects: 1. The readback comparison mechanism of this invention can detect write errors caused by hardware factors such as vibration and power supply fluctuations immediately after writing, ensuring the immediate integrity of the written data; fundamentally eliminating the risk of data loss; by performing physical readback and byte-by-byte full comparison immediately after writing, the judgment standard for successful writing is changed from unstable and unreliable status register signals to stable and reliable data reproduction results; at the same time, the HMAC-SHA256 signature mechanism can identify subsequent tampering of stored data and aging bit errors in long-term storage, providing cryptographic-level security authentication.

[0013] 2. This invention employs a complementary dual-verification mechanism: write-layer errors are detected by readback comparison, while tampering and aging errors are detected by HMAC, covering security requirements throughout the entire storage lifecycle. It has low computational overhead and is suitable for critical data protection in extreme physical environments or for resource-constrained embedded flight data recorders. Logically, this method does not rely on the integrity of the communication link or the stability of the device state, making it particularly suitable for high-value scenarios such as aircraft black boxes, industrial equipment collision recording, and autonomous driving accident data storage. It can ensure the physical integrity of core data at the moment of collision or impact. Combined with the physical isolation design of the backup storage area, it forms the "last line of defense" for data security.

[0014] 3. This invention has good versatility and system compatibility: The method is a verification logic layer independent of specific hardware, and is not limited to specific types of storage media, communication interfaces, or main controller platforms. Whether using SPI, SDIO, or I2C interfaces, whether connecting to SD cards, eMMC, or NAND Flash, and whether using raw sector read / write or file system abstraction, the core solution of this invention can be applied. Attached Figure Description

[0015] Figure 1 This is a flowchart of the control logic of the present invention. Detailed Implementation

[0016] To make the technical problems to be solved, the technical solutions, and the beneficial effects of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present invention and are not intended to limit the present invention.

[0017] like Figure 1 As shown, an aircraft data storage verification method based on post-write readback comparison includes a main controller, a main memory, and an aircraft data acquisition module installed on the aircraft. The main controller is connected to the aircraft data acquisition module and the main memory, and the method is performed according to the following steps:

[0018] S1. The aircraft data acquisition module collects flight data at a fixed sampling rate and generates raw data frames. S2. Calculate the HMAC-SHA256 signature after serializing the original data frame, and append the signature to the end of the data frame to form a signed data unit. S3. The main controller forcibly writes a signed data unit to a target physical address in the main memory; at the same time, the main controller reads all the data of the data unit from the same physical address back to the main controller's volatile memory, forming a readback data unit; S4. The main controller compares the read data unit with the written data unit byte by byte. If every byte is completely consistent, the write operation is determined to be physically successful. If any byte is inconsistent or the read operation fails, the write operation is determined to be physically failed. S5. When it is determined that the physical write is successful, continue to repeat steps S1-S4; when it is determined that the physical write fails, the main controller immediately executes the preset fault tolerance strategy.

[0019] This invention uses an aircraft data acquisition module to collect flight data such as IMU, GPS, and attitude angles at a fixed sampling rate, generating raw data frames. Then, the raw data frames are signed using the HMAC algorithm. An HMAC-SHA256 signature is calculated after serializing the raw data frames and appended to the end of the data frames to form signed data units. The main controller then writes the data units to the main memory via a communication interface. Communication interfaces include, but are not limited to, SPI, SDIO, SDMMC, I2C, and MMC. The main memory includes, but is not limited to, pluggable or solderable non-volatile memory such as SD cards, eMMC, NAND Flash, and NOR Flash.

[0020] After the write operation is completed, the main controller immediately reads all the data from the same physical address back to the main controller's volatile memory via the same communication interface, forming a readback data unit. "Immediately" refers to the shortest possible time window after the write operation is completed, which typically ranges from one instruction cycle to several hundred microseconds. The readback operation uses the same communication clock frequency as the write operation, but a reduced frequency mode can also be used to improve stability. The target physical address for the readback is exactly the same as the target address for the write, accurate to the sector or byte level. If an interface timeout or no response occurs during the readback process, the S5 fault tolerance strategy is directly triggered, and the write operation is considered a physical failure.

[0021] The main controller compares the readback data unit with the original data unit written in step S3 byte by byte in RAM: if every byte of the readback data unit is completely consistent with the corresponding byte of the original data unit, the write operation is determined to be physically successful and the data unit has been reliably written to disk; if any byte is inconsistent, or if the readback fails due to the storage medium not responding, the data is determined to be corrupted or lost and the write operation is physically failed.

[0022] Specific implementations of byte-by-byte comparison include, but are not limited to: byte-by-byte XOR operations, standard library comparison functions such as memcmp, and hardware acceleration methods such as DMA batch comparison. Regardless of the implementation method, the core principle is to perform a 100% coverage comparison of the entire data unit, rather than relying on indirect verification methods such as checksums or hash digests. Byte-by-byte comparison provides more comprehensive coverage, and the system's comparison overhead is controllable. Its time consumption can be estimated using the following formula: T_compare = N × T_byte, Where N is the number of bytes in the data unit, and T_byte is the time taken for a single byte comparison operation. Taking a main controller operating frequency of 160MHz as an example, a single byte comparison requires approximately 1-3 instruction cycles (approximately 6-19 nanoseconds), and the total time for a full comparison of 512 bytes is approximately 3-10 microseconds, which is much less than the 1000Hz acquisition cycle (1000 microseconds). Therefore, byte-by-byte comparison will not affect the normal execution of the real-time acquisition task.

[0023] After comparing each segment, when a physical write failure is determined, the main controller immediately executes a preset fault tolerance strategy. The fault tolerance strategy includes: rewriting the data unit that needs to be written to a backup memory, which is connected to the main controller. The physical connection and communication link between the backup memory and the main controller operate independently of the physical connection and communication link between the main memory and the main controller.

[0024] This backup storage is a storage resource that is physically and communication-link-independent from the external storage medium, ensuring that a single impact event will not cause both to fail simultaneously. For example, if the main memory is connected to an SD card via an SDMMC interface, the backup storage can be the Flash memory built into the main controller (connected via the AHB / APB internal bus and physically isolated from the external SDMMC bus). The backup storage can also be a non-volatile EEPROM, FRAM, or NVRAM built into the main controller, or an external storage medium connected via a backup interface.

[0025] The triggering condition for the fault tolerance strategy can be set to "trigger upon single comparison failure" or "trigger after M consecutive comparison failures" (M is a preset positive integer). The single-failure trigger mode is suitable for scenarios with extremely high data reliability requirements (such as flight data recorder black boxes), where no data loss is allowed; the M consecutive failure trigger mode is suitable for scenarios that need to balance real-time performance and reliability (such as industrial control), which can avoid misjudgments and excessive backup switching caused by occasional electrical interference.

[0026] Step S3 also includes a data buffering step, which is as follows: S11. The data unit to be written is first stored in a first-in-first-out (FIFO) buffer queue; S12. After the storage verification task retrieves data units from the queue asynchronously, it executes the closed-loop verification process from S3 to S5 in sequence. The depth requirement of the FIFO buffer queue is estimated using the following formula: Queue_Depth ≥ T_store × F_sample, Where T_store is the average time taken for a single write and verification, including the complete process of steps S3-S5, and F_sample is the data sampling rate; when T_store=5ms and F_sample=1000Hz, the queue depth is at least 5 data units. To ensure a safety margin, the actual queue depth is usually set to 2-4 times this theoretical minimum value.

[0027] When the FIFO buffer queue depth exceeds the preset threshold, the main controller automatically starts the degradation strategy, temporarily skipping the verification task to perform raw writing or increasing the priority of the verification task to ensure that the storage task can still be completed under transient pressure.

[0028] Step S4 also includes a link recovery step, which is as follows: when the main controller detects that the number of comparison failures exceeds the preset link failure threshold, the main controller attempts to restore normal communication with the main memory through initialization and reset. If communication is successfully restored, the main controller will continue to write subsequent data units into the main memory and write back the data temporarily stored in the backup memory to the main memory. If communication cannot be restored after multiple attempts, the main controller will continuously write data to the backup storage and report an alarm signal to notify maintenance personnel to intervene.

[0029] In addition, an anomaly detection module is also connected to the main controller. The anomaly detection module is used to detect whether the aircraft is experiencing or about to experience a high overload impact through sensors. When it is determined that a high overload impact is being encountered or about to be encountered, the main controller sets the flag bit with a hardware instruction and stores the flag bit in the shared memory of the main controller; When the main controller performs write and verification tasks, it first checks whether the flag bit is valid. If the flag bit is valid, it immediately executes the fault tolerance strategy and records the fault log until the flag bit is cleared.

[0030] The fault log records relevant information about the failure event in a pre-defined fault log area. This information includes, but is not limited to: event timestamp, target physical address of the failed write, number of retries, spare storage area number used, and data unit size. The fault log provides a detailed data foundation for post-event analysis.

[0031] To verify the technical effects of this invention, a verification platform was built based on an ESP32-P4 microcontroller (main controller) and an SD card (external storage medium, connected via an SDMMC interface). The system uses the FreeRTOS real-time operating system and continuously acquires, stores, and verifies six-axis inertial sensor data driven by a 1000Hz hardware timer.

[0032] Physical collision test Test conditions: The system circuit board, containing the main controller and SD card, was encapsulated in a 3D-printed PLA shatterproof shell. The shell design employed a mesh-filled structure to enhance energy absorption and cushioning. The device was subjected to free fall from an altitude equivalent to normal flight attitude (approximately 1 to 2 meters), impacting a hard concrete surface to simulate the extreme impact conditions of a real aircraft crash. The impact location for each fall was not restricted to simulate unpredictable random impact angles.

[0033] Test Method: During the descent, the system continuously collected acceleration and angular velocity data at a frequency of 1000Hz. After Mahony quaternion attitude filtering, the data was encapsulated into CSV format data rows and written to an SD card using the S1-S5 closed-loop verification method of this invention. After the impact, the SD card was removed, and the complete CSV format flight data file was read from the host computer software "Sky Shield Flight Accident Analysis Platform". On the host computer, all data sectors read were compared byte by byte with the original written data cached in the system RAM. The integrity score of the data (based on timestamp continuity and field integrity calculation) and the waveform continuity of the acceleration and angular velocity time series were verified simultaneously.

[0034] Test results: The byte-by-byte comparison results of all sectors were completely consistent; the data integrity score displayed by the host computer software was 100.0%; the time-domain waveforms of acceleration and angular velocity were continuous and complete, and there were no frame drops or abnormal jumps within the ±5-second accident analysis window; The automatic accident point marking function is operating normally, and the marking status is displayed as "[OK] Marked", which proves the robustness of the intelligent accident marking algorithm under extreme impact.

[0035] The test data is as follows: Simulated number of impacts 3 times 3 times Data volume per write 10,000 records 10,000 records Data integrity 67.2% (significant data loss) 100% (zero data loss) Loss of accident site 2 / 3 of the critical ±5 seconds of data loss 0 missing abnormal waveform jump Multiple abnormal breakpoints Waveform Continuous Smooth

[0036] Experimental conclusion: This physical collision experiment powerfully demonstrates that, under extreme high overload impacts sufficient to damage ordinary electronic devices, the closed-loop verification method proposed in this invention—"immediately read back after writing and compare byte by byte"—can fundamentally guarantee the physical authenticity and integrity of critical data on external storage media. This method effectively eliminates the risk of data loss in traditional status register-dependent schemes, increasing data write reliability from less than 70% to 100%.

[0037] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included within the scope of the present invention.

Claims

1. A method for verifying aircraft data storage based on post-write readback comparison, comprising a main controller, a main memory, and an aircraft data acquisition module installed on the aircraft, wherein the main controller is connected to the aircraft data acquisition module and the main memory, characterized in that: Follow these steps: S1. The aircraft data acquisition module collects flight data at a fixed sampling rate and generates raw data frames. S2. Calculate the HMAC-SHA256 signature after serializing the original data frame, and append the signature to the end of the data frame to form a signed data unit. S3. The main controller forcibly writes a signed data unit to a target physical address in the main memory; at the same time, the main controller reads all the data of the data unit from the same physical address back to the main controller's volatile memory, forming a readback data unit; S4. The main controller compares the read data unit with the written data unit byte by byte. If every byte is completely consistent, the write operation is determined to be physically successful. If any byte is inconsistent or the read operation fails, the write operation is determined to be physically failed. S5. When it is determined that the physical write is successful, continue to repeat steps S1-S4; when it is determined that the physical write fails, the main controller immediately executes the preset fault tolerance strategy.

2. The aircraft data storage verification method based on post-write readback comparison according to claim 1, characterized in that: The fault-tolerance strategy includes: rewriting the data units that need to be written to a backup memory, which is connected to the main controller, and the physical connection and communication link between the backup memory and the main controller operates independently of the physical connection and communication link between the main memory and the main controller.

3. The aircraft data storage verification method based on post-write readback comparison according to claim 2, characterized in that: The main memory is a SD card connected to the main controller via the SDMMC interface, and the backup memory is a non-volatile memory such as Flash, EEPROM, FRAM and NVRAM built into the main controller or an external storage medium connected via a backup interface.

4. The aircraft data storage verification method based on post-write readback comparison according to claim 1, characterized in that: Step S3 further includes a data buffering step, which is as follows: S11. The data unit to be written is first stored in a first-in-first-out (FIFO) buffer queue; S12. After the storage verification task retrieves data units from the queue asynchronously, it executes the closed-loop verification process from S1 to S3 in sequence. The depth requirement of the FIFO buffer queue is estimated using the following formula: Queue_Depth ≥ T_store × F_sample, Where T_store is the average time taken for a single write and verification, including the complete process of steps S3-S5, and F_sample is the data sampling rate; When the FIFO buffer queue depth exceeds a preset threshold, the main controller automatically initiates a degradation strategy, temporarily skipping the verification task to perform raw writing or increasing the priority of the verification task, so as to ensure that the storage task can still be completed under transient pressure.

5. The aircraft data storage verification method based on post-write readback comparison according to claim 1, characterized in that: The main controller is also connected to an anomaly detection module, which is used to detect whether the aircraft is experiencing or is about to experience a high overload impact through sensors. When it is determined that a high overload impact is being encountered or about to be encountered, the main controller sets the flag bit with a hardware instruction and stores the flag bit in the shared memory of the main controller; When performing write and verification tasks, the main controller first checks whether the flag bit is valid. If the flag bit is valid, it immediately executes the fault tolerance strategy and records the fault log until the flag bit is cleared.

6. The aircraft data storage verification method based on post-write readback comparison according to claim 1, characterized in that: Step S4 also includes a link recovery step, which is as follows: when the main controller detects that the number of comparison failures exceeds the preset link failure threshold, the main controller attempts to restore normal communication with the main memory through initialization and reset. If communication is successfully restored, the main controller will continue to write subsequent data units into the main memory and write back the data temporarily stored in the backup memory to the main memory. If communication cannot be restored after multiple attempts, the main controller will continue to write data to the backup storage and report an alarm signal to notify maintenance personnel to intervene.

Images