Air cargo locator compliance tracking method and system

Abstract

This invention discloses a compliant tracking method and system for air cargo locators. Through the close integration of steps, it realizes full lifecycle management from device startup to data upload and anomaly handling. It introduces the concept of a chain of evidence, tracking not only the location of the cargo but also, more importantly, the radio frequency compliance status of the device itself, ensuring data credibility. By writing a unique DevID and certificate, it prevents the device from being counterfeited. Binding the device to a specific air cargo container / waybill ensures the accuracy of the tracking object. Strict hardware self-tests ensure that the device cannot enter communication mode when there is a hardware malfunction, eliminating the risk of operating with defects.

Description

Technical Field

[0001] This invention relates to the field of air cargo, and more particularly to a compliant tracking method and system for air cargo locators. Background Technology

[0002] Existing aviation logistics positioning technologies have significant technical shortcomings and compliance risks when dealing with continuous tracking across airports, borders, and multiple operator networks. First, while conventional IoT locator solutions are widely applicable to ground asset tracking, their radio frequency (RF) control heavily relies on software switches, configuration strategies, or manual compliance declarations, lacking a physical-level mandatory constraint mechanism. This makes it difficult to fundamentally meet the stringent RF emission prohibition requirements in air transport. Second, current mainstream power supply and shutdown control solutions based on flight status judgment can only infer the takeoff and landing status of the equipment through sensor parameters such as speed, acceleration, and air pressure to control the power on or off of the communication module. Their core logic is limited to "when to turn communication off / on," failing to provide physical proof of silence during the RF emission prohibition period, thus raising doubts about airworthiness compliance. Furthermore, while existing indoor and outdoor tracking solutions for aviation containers effectively solve the spatiotemporal visibility problem of "where are the assets," achieving location monitoring within cargo terminals and during transport transfers, they also fail to address the core pain point of verifying physical RF silence during flight emission prohibition periods. Furthermore, high-precision positioning and multi-source fusion positioning technologies for aircraft primarily focus on flight path correction and high-precision position calculation, which is not equivalent to the compliance tracking of air cargo locators during transport in the cargo hold of passenger or cargo aircraft. High-speed motion detection solutions rely on the terminal being under cellular network monitoring or mobility management, which not only cannot directly prove radio frequency silence during prohibited phases but also faces the risk of failure when the aircraft leaves base station coverage before takeoff or after landing. In summary, existing technologies generally lack the hardware-level closed-loop verification capability to achieve "absolute radio frequency silence" for air cargo locators throughout the entire flight lifecycle.

[0003] In summary, a compliant tracking method and system for air cargo locators is needed to address the shortcomings of existing technologies. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a compliant tracking method and system for air cargo locators, aiming to solve the aforementioned problems.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a compliant tracking method for air cargo locators, comprising the following steps:

[0006] Step S1: Initialize pre-configuration. During the device initialization phase, the system securely writes the device key and identity, initializes the evidence chain head parameters, binds freight assets, pre-configures compliance policies, and performs hardware self-checks.

[0007] Step S2: Data acquisition. In the default silent state, the device cuts off the radio frequency power supply through the hardware latch unit, and after being woken up, it collaboratively acquires positioning data, sensor summary and radio frequency physical feedback to construct a silent evidence frame containing trajectory summary and preorder hash, which is then written to non-volatile memory through chain authentication.

[0008] Step S3: Communication decision and reporting. Through multi-condition logic and judgment of the radio frequency release gate, after confirming that all safety conditions are met, the communication module is powered on within a time limit to complete the cloud challenge response and upload data in batches. Once the timeout or failure occurs, the power is immediately cut off and the cause of the abnormality is recorded in the evidence chain.

[0009] Step S4: Cloud verification and closed loop. The integrity of the evidence chain is verified by recalculating the chain authentication value, verifying the radio frequency physical feedback and trajectory summary, generating a compliance conclusion, returning a confirmation receipt to the device, triggering data cleanup and compliance report output, and activating the device's permanent silent locking mechanism when a serious anomaly is detected.

[0010] Optionally, step S1 is implemented in the following manner:

[0011] Write the unique device identity DevID, device certificate or shared key Kdev to the device locator, initialize the monotonic counter Seq_0, initial time Time_0, first frame digest H_0 and policy version PolicyVer, and write the above information to the protected area of ​​non-volatile memory. Bind the locator to the air cargo pallet number, air container number, air waybill number or customer asset number, and write the airworthiness / RF silence policy, including the default prohibition rule, RF_OFF threshold, release gate condition, reporting time window, dual SIM retry budget, abnormal latching level and platform certificate fingerprint. Sequentially check the RF security latch unit, load side voltage / current sampling, communication module RDY / STATUS reading, SIM_VCC detection, UART_TX suppression, non-volatile memory CRC and RTC monotonicity; do not allow entry into communication mode if self-test fails.

[0012] Optionally, step S2 is implemented in the following manner:

[0013] Step S21: Default RF silence and low-power listening. After the locator is powered on, the hardware latch unit forces the communication module to enter a physical silence state that does not depend on software initialization. The main control collects the RF feedback, establishes a silence baseline, and immediately locks it when an anomaly is detected. Only the RTC and low-power sensor are allowed to listen to specific trigger events in the continuous silence state of the communication module, so that the evidence chain counter and RTC monotonically increase.

[0014] Step S22: Wake-up event determination and data acquisition. After the main controller wakes up, it records the trigger source and collects positioning and sensing data without opening the radio frequency transmission link. The relevant information is packaged into a trajectory block and a summary is calculated to bind the evidence frame with the same sequence number.

[0015] Step S23: RF physical feedback sampling and RF_OFF determination. The main controller reads the RF enable command and the multi-dimensional physical feedback of the load side voltage and current. It performs multiple sampling, temperature compensation and deviation correction on the analog quantity to eliminate glitches and interference. It determines the threshold based on the module specifications and environmental drift for comprehensive determination. If an abnormal power-on or state contradiction is found under the shutdown command, the abnormal flag is immediately set and the lockout state is entered to prohibit short window reporting.

[0016] Step S24: Silent evidence frame construction, authentication and writing. The evidence frame containing device identity, multi-dimensional status and radio frequency physical feedback is bound with the preceding hash. An anti-tampering chain authentication tag is generated through HMAC or digital signature. A secure writing mechanism is adopted, which first writes the to-submit flag and content, then reads back for verification, and finally updates the submission flag.

[0017] Step S25: Health check and data retention of the evidence chain. The master controller performs integrity checks on the sequence and time increment, chain head hash and storage CRC. After power failure and restart, it reads the last complete submission frame to generate a recovery frame that records the interruption reason and RTC status. Based on the cloud confirmation status, it securely compresses or deletes the uploaded old intervals, retains unconfirmed data and updates the latest chain head summary, unconfirmed interval start and end Seq and anomaly index.

[0018] Optionally, step S21 is implemented in the following manner:

[0019] Step S211: Establish default shutdown state. After the locator is powered on, the radio frequency safety latch unit defaults to output shutdown or reset hold, so that the communication module is in a physical power-off, reset hold or transmit prohibition state.

[0020] Step S212: Acquire silent baseline. The main controller reads the feedback values ​​of RF_EN_cmd, Vrf, Irf, RF_RDY, SIM_VCC, and TX_inhibit to establish silent baseline. If the command is to shut down but there is still abnormal voltage and current on the load side, an abnormal frame is immediately generated and locked.

[0021] Step S213: Configure the wake-up source, allowing only RTC, low-power acceleration events, loading / unloading shocks, air pressure changes, abnormal power / temperature, maintenance magnetic triggers, or signed maintenance commands to trigger short-term wake-up of the main controller; the cellular communication module must not be used as a normal wake-up source;

[0022] Step S214: Enter low-power listening mode. The main controller and sensors maintain listening in a low-power state, the communication module remains in a no-send state, and the evidence chain counter and RTC remain monotonically increasing.

[0023] Optionally, step S22 is implemented in the following manner:

[0024] Step S221: Identify the wake-up reason. After the main controller wakes up, it first records the trigger source.

[0025] Step S222: Collect positioning and sensing data. Without opening the radio frequency transmission link, collect GNSS coordinates, time, velocity, HDOP, acceleration, air pressure, temperature, battery voltage, estimated battery internal resistance, remaining storage space, and device attitude information.

[0026] Step S223: Form a track block by packaging one or more positioning points, sensor sampling values ​​and event flags into TrackBlock_i, and calculate TrackHash_i or CRC_i;

[0027] Step S224: Generate an environmental state summary, obtaining EnvState_i based on speed, air pressure change, GNSS effectiveness, motion duration, airport geofencing, and historical flight path rules.

[0028] Optionally, step S23 is implemented in the following manner:

[0029] Step S231: Read the instruction status and physical feedback. The main controller reads RF_EN_cmd, load-side voltage Vrf, load-side current Irf, communication module gating status, module reset pin, baseband wake-up pin, and optional external comparator output.

[0030] Step S232: Perform filtering and threshold compensation. Perform multiple sampling, temperature compensation, ADC deviation correction and glitch filtering on the Vrf / Irf analog quantity. The thresholds Vth and Ith are determined according to the communication module specifications, MOS leakage current, sampling resistor error and temperature drift.

[0031] Step S233: Calculate and process feedback contradictions, calculate RF_OFF conditions, and the main controller comprehensively determines RF_OFF based on multi-dimensional conditions such as RF enable, voltage and current thresholds, ready state and SIM card status. When a contradiction between the instruction and physical feedback is detected, the RF credibility is set to zero, the cause of the anomaly is recorded, the latching mechanism is triggered, and the short window reporting is blocked.

[0032] Optionally, step S3 is implemented in the following manner:

[0033] Step S31: Radio frequency release gate determination. In the radio frequency release gate determination stage, strict multi-condition logic AND operation is performed on the continuity of the evidence chain, radio frequency physical silence feedback, ground safety environment, equipment health status, reporting time window, strategy effectiveness and energy reserve to output a permission signal. Following the fail-safe principle, any unknown or abnormal state is judged as a prohibition on transmission by default.

[0034] Step S32: Short window communication, dual SIM selection and controlled reporting. After the release door is opened, timed power-on and network selection are performed. After verifying the identity through challenge response, the chain head and status are uploaded first, and then evidence frames and trajectory data are reported in batches in sequence. If network failure or timeout occurs, power is cut off and the reason for failure is recorded in the evidence chain.

[0035] Optionally, step S4 is implemented in the following manner:

[0036] Step S41: Cloud-based evidence chain verification and trajectory consistency verification. The cloud verifies data integrity by recalculating the chain authentication value, cross-verifies the consistency between radio frequency physical feedback and trajectory summary, confirms that there was no illegal transmission during flight, and generates a closed-loop judgment conclusion on compliance or abnormality based on this.

[0037] Step S42: Receipt processing, compliance report output and anomaly closure. After returning the start and end sequence numbers of the verified data, the platform deletes or compresses the confirmed data and outputs a compliance report containing the silent period, reporting period and anomaly cause. If there is a broken evidence chain or serious anomaly due to physical feedback contradictions, permanent silent closure will be triggered until manual maintenance.

[0038] An air cargo locator compliance tracking system, employing the aforementioned air cargo locator compliance tracking method, includes a pre-configuration and self-test module, a data acquisition and evidence construction module, a communication decision and reporting module, and a cloud verification and closed-loop module;

[0039] The pre-configuration and self-test module is used during the device initialization phase to securely write device keys and identities, initialize the evidence chain head parameters, bind freight assets, pre-configure compliance policies, and perform hardware self-tests.

[0040] The data acquisition and evidence construction module is used to cut off the radio frequency power supply through the hardware latch unit when the device is in default silent state, and after being woken up, it will collect positioning data, sensor summary and radio frequency physical feedback to construct a silent evidence frame containing trajectory summary and preorder hash, and write it to non-volatile memory through chain authentication.

[0041] The communication decision and reporting module is used to power on the communication module within a time limit after confirming that all safety conditions are met through multi-condition logic and judgment of the radio frequency release gate, complete the cloud challenge response and upload data in batches. Once the time limit is exceeded or failure occurs, the power is immediately cut off and the abnormal reason is recorded in the evidence chain.

[0042] The cloud-based verification and closed-loop module is used to verify the integrity of the evidence chain and generate compliance conclusions by recalculating chained authentication values, verifying radio frequency physical feedback and trajectory summaries, returning confirmation receipts to the device, triggering data cleanup and compliance report output, and activating the device's permanent silent locking mechanism when a serious anomaly is detected.

[0043] The data acquisition and evidence construction module includes a low-power monitoring submodule, a trajectory perception submodule, a physical feedback sampling submodule, and an evidence chain construction submodule;

[0044] The low-power monitoring submodule and the physical feedback sampling submodule are used to force the communication module to physically disable using a hardware latch unit, allowing only the RTC and low-power sensors to operate, establishing an RF silence baseline, and monitoring specific wake-up events.

[0045] The trajectory perception submodule is used to collect positioning data, environmental data, and motion status without activating the radio frequency transmission link, and package them to generate a trajectory summary.

[0046] The physical feedback sampling submodule is used to read the RF control commands and physical feedback quantities such as voltage and current on the load side. Through multiple sampling and temperature compensation algorithms, it accurately determines whether the RF module is in a true physical off state.

[0047] The evidence chain construction submodule is used to bind device identity, status data, physical feedback and preceding hash value, generate tamper-proof chain authentication tags through HMAC or digital signature, and securely write them to non-volatile memory.

[0048] The beneficial effects of this invention are:

[0049] 1. In this invention, through the close connection of steps, full lifecycle management from device startup to data upload to anomaly handling is realized. The concept of evidence chain is introduced, which not only tracks the location of goods, but also focuses on tracking the radio frequency compliance status of the device itself to ensure the credibility of the data. By writing a unique DevID and certificate, the device is prevented from being counterfeited. Binding the device to a specific air waybill ensures the accuracy of the tracked object. Strict hardware self-test ensures that the device cannot enter the communication mode when there is a hardware failure, eliminating the risk of operating with defects.

[0050] 2. In this invention, a hardware latch unit is used to force physical transmission ban, rather than relying solely on software shutdown, which completely eliminates the hidden dangers of radio frequency interference in air transport. Chain authentication is introduced, and any tampering with historical data will cause the chain to break, which greatly enhances the non-repudiation of data and eliminates the risk of radio frequency mis-transmission caused by the software not being fully loaded at the moment of device startup. By establishing a silent baseline, once it is found that the command is shut down but the load still has voltage, it is immediately locked, achieving millisecond-level fault isolation.

[0051] 3. In this invention, while ensuring positioning accuracy, the high-power radio frequency module is kept running continuously, which significantly extends battery life. By using a calculated summary instead of the original data storage, storage space is reduced, and the summary value is kept confidential from the cloud before being uploaded for verification. Temperature compensation and glitch filtering solve the problem of misjudgment in industrial environments, ensuring accurate judgment of radio frequency status even under extreme temperature or voltage fluctuations. Multidimensional judgment is more reliable than single signal detection, effectively preventing hackers from bypassing detection by forging a single line signal. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of a method flow of the present invention.

[0053] Figure 2 This is a schematic diagram of a radio frequency release gate determination logic according to the present invention.

[0054] Figure 3 This is a schematic diagram of a cloud-based verification and compliance report generation process according to the present invention.

[0055] Figure 4 This is a schematic diagram of a system structure according to the present invention.

[0056] Figure 5 This is a schematic diagram of a silent evidence frame and chain-like organizational structure according to the present invention. Detailed Implementation

[0057] To more clearly illustrate the technical solutions in the embodiments of the invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] like Figures 1 to 3 As shown, a compliant tracking method for air cargo locators includes the following:

[0059] During the initialization phase of the device, the system securely writes the device key and identity, initializes the head parameters of the evidence chain, binds freight assets, pre-configures compliance policies, and performs hardware self-checks.

[0060] Data acquisition: In the default silent state, the device cuts off the radio frequency power supply through the hardware latch unit, and after being woken up, it collaboratively acquires positioning data, sensor summary and radio frequency physical feedback to construct a silent evidence frame containing trajectory summary and preorder hash, which is then written to non-volatile memory through chain authentication.

[0061] Communication decision-making and reporting, through multi-condition logic and judgment radio frequency release gate, after confirming that all safety conditions are met, the communication module is powered on within a time limit to complete the cloud challenge response and upload data in batches. Once the timeout or failure occurs, the power is immediately cut off and the cause of the abnormality is recorded in the evidence chain.

[0062] Cloud-based verification and closed-loop processing verifies the integrity of the evidence chain and generates compliance conclusions by recalculating chained authentication values, verifying RF physical feedback and trajectory summaries, returning confirmation receipts to the device, triggering data cleanup and compliance report output, and initiating the device's permanent silent locking mechanism when a serious anomaly is detected.

[0063] Specifically, it includes the following:

[0064] Each round of execution begins with "default no transmission". The communication module is only allowed to power on within a limited time if the evidence chain, radio frequency physical feedback, environmental status, device health, reporting window, policy version, and energy budget are all satisfied. If any condition is unknown, contradictory, or abnormal, the system enters the abnormal lockout branch and writes the cause into the evidence chain.

[0065] S1: Equipment manufacturing, board mounting, and strategy initialization. The process is characterized by including:

[0066] S1-1: Write device identity and key materials. During device manufacturing, assembly, or maintenance, write a unique device identity (DevID), device certificate, or shared key (Kdev) to the locator. The key can be stored in the security chip, main control security area, TEE, or PUF derived key area and is not exported with ordinary trajectory data.

[0067] S1-2, Initialize the evidence chain head, the master initializes the monotonic counter Seq_0, the initial time Time_0, the first frame digest H_0 and the policy version PolicyVer, and writes the above information into the protected area of ​​the non-volatile memory.

[0068] S1-3, bind air logistics assets, bind the locator to the air cargo pallet number, air container number, air cargo box number, waybill number or customer asset number; the binding relationship can be completed by maintenance tools, barcode scanning terminals or signature configuration issued by the platform.

[0069] S1-4, load compliance policies and write airworthiness / RF silence policies, including default rules for prohibiting transmission, RF_OFF threshold, release gate conditions, reporting time window, dual SIM retry budget, abnormal lockout level and platform certificate fingerprint.

[0070] S1-5, self-tests key hardware links, sequentially testing the RF security latch unit, load-side voltage / current sampling, communication module RDY / STATUS reading, SIM_VCC detection, UART_TX suppression, non-volatile memory CRC, and RTC monotonicity; if the self-test fails, entry into communication mode is not allowed.

[0071] S2: Default RF silence and low-power monitoring. The process is characterized by including:

[0072] S2-1, Establish the default shutdown state. After the locator is powered on, the RF safety latch unit defaults to output shutdown or reset hold, so that the communication module is in a physically powered-off, reset hold, or transmit-prohibited state; this default state does not rely on software to complete the initialization.

[0073] S2-2, Acquire silent baseline. The main controller reads feedback quantities such as RF_EN_cmd, Vrf, Irf, RF_RDY, SIM_VCC, and TX_inhibit to establish silent baseline. If the command is to shut down but there is still abnormal voltage / current on the load side, an abnormal frame is immediately generated and locked.

[0074] S2-3, Configure wake-up source, only allow RTC, low power acceleration events, loading and unloading shocks, air pressure changes, power / temperature abnormalities, maintenance magnetic triggers or signed maintenance commands to trigger short-term wake-up of the main controller; cellular communication modules must not be used as normal wake-up sources.

[0075] S2-4, enter low-power listening mode. The main controller and sensors maintain listening in a low-power state, the communication module remains in a no-send state, and the evidence chain counter and RTC remain monotonically increasing.

[0076] S3: Wake-up event determination and data acquisition. The process is characterized by including:

[0077] S3-1 identifies the wake-up reason. After the main controller wakes up, it first records the trigger source, such as timed sampling, motion events, loading and unloading impacts, sudden changes in air pressure, GNSS strategy triggers, maintenance commands, or retry windows after the last network failure.

[0078] S3-2 collects positioning and sensing data. Without opening the radio frequency transmission link, it collects information such as GNSS coordinates, time, speed, HDOP, acceleration, air pressure, temperature, battery voltage, estimated battery internal resistance, remaining storage space, and device attitude. Even when GNSS is unavailable, it still records time, motion / air pressure / battery summary, and anomaly indicators.

[0079] S3-3, forming a track block, packages one or more positioning points, sensor sample values, and event flags into a TrackBlock_i, and calculates TrackHash_i or CRC_i. Track blocks can be stored independently, but must be bound to evidence frames with the same sequence number via TrackHash_i.

[0080] S3-4 generates an environmental state summary, obtaining EnvState_i based on speed, air pressure changes, GNSS effectiveness, motion duration, airport geofencing, historical flight path rules, etc. EnvState_i is only used as one input to the release gate and is no longer the sole criterion for "flying / non-flying".

[0081] S4: Radio frequency physical feedback sampling and RF_OFF determination. The process is characterized by including:

[0082] S4-1 reads command status and physical feedback. The main controller reads RF_EN_cmd, load-side voltage Vrf, load-side current Irf, communication module PWR_GOOD / RDY / STATUS, SIM_VCC, UART_TX gating status, module reset pin, baseband wake-up pin, and optional external comparator output.

[0083] S4-1-1, the hardware composition of the RF safety latch unit, adopts a combined structure of "power supply high-side hard shutdown + control line low-side suppression + hardware timeout reset". The battery output enters the dedicated power supply branch VBAT_RF of the communication module after being protected by a fuse / PTC. This branch can be controlled by the communication module power enable pin of a back-to-back P-channel MOSFET, a high-side load switching chip, or a PMIC. The above devices are in an off state by default due to pull-down / pull-up resistors, so that the communication module does not have the conditions to power on when the main controller is reset, the firmware is not started, or the strategy is unknown.

[0084] S4-1-2, hardware suppression of the transmission related control line. In addition to cutting off VBAT_RF, the RF safety latch unit can also be gated through N-channel MOSFETs, analog switches, tri-state gates or logic AND gates to the communication module PWRKEY, RESET, UART_TX, baseband wake-up pin and SIM_VCC. When TX_inhibit=1, even if the main control serial port is accidentally triggered or the communication module firmware is abnormal, the transmission link will still remain in the suppressed state.

[0085] S4-1-3, latch release and forced fallback: The communication module only outputs a timed permission from the main controller to the SR latch, electronic fuse, or PMIC_EN control terminal when the S7 release gate Gate=1; simultaneously, an independent hardware timer or watchdog timer T_tx is used. Upon timeout, main controller power failure, gate revocation, or any RFProof anomaly, the hardware automatically pulls back to the RF_OFF state. Therefore, RF shutdown does not rely on a single software variable, but is achieved jointly by the power switch, reset hold, SIM power gating, and transmit path suppression.

[0086] S4-1-4, Feedback Sampling and Isolation Method: Vrf is preferably acquired through a resistor divider + ADC or comparator; Irf is preferably acquired through a milliohm sampling resistor + current sense amplifier; RDY / STATUS, PWR_GOOD, SIM_VCC, and TX_inhibit are acquired through GPIO or comparator inputs and together form RFProof. Since the positioner's internal circuit is a low-voltage common ground circuit, optocoupler isolation is usually not provided; if there is an external maintenance interface, ground test fixture, or high-noise peripheral, digital isolators or optocoupler isolation can be used only on the external interface side, and it is not a necessary condition for RF shutdown.

[0087] S4-2 performs filtering and threshold compensation, performing multiple sampling, temperature compensation, ADC deviation correction and glitch filtering on analog quantities such as Vrf / Irf; the thresholds Vth and Ith are determined according to the communication module specifications, MOS leakage current, sampling resistor error and temperature drift.

[0088] S4-2-1, Dynamic Threshold Model: Dynamic thresholds are preferred for Vth and Ith rather than a single fixed threshold. During factory calibration, board maintenance, or the S2 silent baseline acquisition phase, the positioner records the mean Vrf value μV0, standard deviation σV0, mean Irf value μI0, standard deviation σI0, calibration temperature T0, and calibration battery voltage VBAT0 in the RF_OFF state. During operation, the thresholds are corrected based on temperature T_i, battery voltage VBAT_i, ADC zero-point drift, sampling resistor error, MOS / PMIC shutdown leakage current, and sampling noise.

[0089] S4-2-2, Threshold Calculation Formula:

[0090] Vth(i)=min{V_ON_min-ΔV_safe,μV0+nσV0

[0091] +kVT·|T_i-T0|+kVB·|VBAT_i-VBAT0|+ΔV_adc+ΔV_margin};

[0092] Ith(i)=min{I_READY_min-ΔI_safe,μI0+nσI0

[0093] +kIT·|T_i - T0|+kIB·|VBAT_i - VBAT0|+ΔI_rsense+ΔI_margin}。

[0094] Among them, V_ON_min is the lowest voltage at which the communication module can enter the power-on / ready state, I_READY_min is the minimum recognizable current before the communication module enters the ready or possible transmission state, n can take values from 3 to 5, and ΔV_safe and ΔI_safe are used to ensure that the determination threshold is always lower than the operating conditions of the communication module.

[0095] S4-2-3, Conservative handling of threshold failure. If the temperature sensor, ADC, sampling resistor, baseline parameter or data manual constraint is missing, the system adopts a more stringent fixed conservative threshold; if the dynamic threshold calculation result exceeds the allowable range, or there is a contradiction between Vrf / Irf sampling and RDY, SIM_VCC, TX_inhibit, then RF_OFF(i) is directly judged as 0 and "unknown means no transmission" is triggered.

[0096] S4-3, Calculate the RF_OFF condition, RF_OFF(i) = (RF_EN_cmd = 0) AND (Vrf < Vth) AND (Irf < Ith) AND (RF_RDY = 0) AND (TX_inhibit = 1) AND (SIM_VCC = 0 or SIM is in the disabled state).

[0097] S4-4, Handle feedback contradictions. If RF_EN_cmd = 0 but Vrf / Irf exceeds the threshold, RDY shows ready, SIM_VCC is abnormally powered on, or TX_inhibit is not effective, then set C_rf to 0, record the reason for the feedback contradiction, enter abnormal locking, and do not allow short-window reporting.

[0098] S5, Construction, authentication and writing of the silent evidence frame. It is characterized in that this process includes:

[0099] S5-1, Assemble the evidence frame header. The evidence frame contains DevID, Seq_i, Time_i, PolicyVer, FirmwareVer, WakeReason_i, PowerState_i, EnvState_i and the exception flag Flags_i.

[0100] S5-2, Write the data digest. The evidence frame writes SensorDigest_i, TrackHash_i and RFProof_i, where RFProof_i includes the radio frequency instruction status, physical feedback and RF_OFF determination result collected in S4.

[0101] S5-3 introduces a pre-sequence digest. The evidence frame contains PrevHash=H_{i-1} and is constrained by a monotonic counter Seq_i and a time time_i to prevent deletion, insertion, swapping, replay, or cross-device copying.

[0102] S5-4 generates a chained authentication value, using HMAC, AES-CMAC, SM3-HMAC, or a digital signature to generate AuthTag_i. Example: H_i = HMAC(Kdev, DevID || Seq_i || Time_i || SensorDigest_i || RFProof_i || TrackHash_i || H_{i-1}).

[0103] S5-5 uses a two-stage write to non-volatile storage. First, it writes the commit flag, frame content, and CRC. Then, it reads back to verify the data and finally updates the commit flag and chain head digest. If the write is interrupted, the next startup can recover the data based on the commit flag or generate a storage exception frame.

[0104] S6, Evidence Chain Health Check and Data Retention. The process is characterized by including:

[0105] 6-1. Check chain continuity. The main controller checks whether Seq is incrementing, whether Time has not rolled back, whether PrevHash is equal to the current chain head, and whether the stored CRC is correct. If these conditions are not met, C_chain is set to 0.

[0106] S6-2 handles interrupts and power outages. If the device loses power during frame writing or sampling, it will read the last complete submission frame after restarting and record the interruption reason, RTC status, and storage verification result as a "power outage recovery frame".

[0107] S6-3 performs segmentation and compression. When the storage space approaches the threshold, old intervals that have been uploaded and confirmed can be compressed or deleted. Evidence frames and corresponding trajectory blocks that have not been confirmed by the cloud must not be overwritten.

[0108] S6-4 maintains the chain head state, locally storing the latest chain head digest LatestHash, the start and end Seq of the local unconfirmed interval, and the index of the abnormal interval, providing input for the release gate and cloud upload.

[0109] S7, Radio frequency release gate determination. The process is characterized by including:

[0110] S7-1 Calculate the evidence chain condition C_chain. C_chain=1 when the evidence chain is continuous, Seq is monotonic, CRC is correct, LatestHash is available, and the unconfirmed interval can be read back; otherwise, C_chain=0.

[0111] S7-2, calculate the radio frequency condition C_rf. C_rf = 1 if the RFProof of one or more recent evidence frames satisfies RF_OFF and there is no feedback contradiction, abnormal readiness, or TX suppression failure; otherwise, C_rf = 0.

[0112] S7-3, calculate the environmental conditions C_env, and determine whether it is within the ground safety window based on EnvState, continuous stationary / low-speed state, stable air pressure, whether the GNSS position is located on the airport ground or in the storage / loading area, and the time interval of the flight segment; when the environment is uncertain, C_env=0.

[0113] S7-4, calculate device health condition C_health. C_health = 1 when RTC has not rolled back, firmware has not been tampered with, policy version is valid, storage is writable, power and temperature meet short-window communication requirements, and casing or installation switch has not triggered an abnormality.

[0114] S7-5 calculates the window, policy, and energy conditions. C_window indicates that the allowed reporting time window has been reached and the retry budget has not been exceeded; C_policy indicates that the platform policy is valid and has not expired; C_energy indicates that the battery capacity and temperature allow this communication.

[0115] S7-6 outputs the gate release result: Gate = C_chain AND C_rf AND C_env AND C_health AND C_window AND C_policy AND C_energy. Any unknown, missing, or abnormal condition is treated as 0, i.e., "unknown means prohibited".

[0116] S8: Short-window communication, dual SIM selection, and controlled reporting. The process includes:

[0117] S8-1, timed opening of RF safety latch: when Gate=1, the main controller allows the RF safety latch unit to open within a limited time T_tx, so that the communication module is powered on; at the same time, a hardware timer is started, which will be forcibly shut down when the time is up.

[0118] S8-2: Select the SIM and PLMN scanning order. The main controller selects the SIM card and frequency band scanning order based on the most recent valid GNSS location, historical PLMN successful records, SIM roaming policy, operator blacklist / whitelist, signal strength, failure reason, and battery remaining.

[0119] S8-3 first uploads the chain head and device status. After the device is attached, it prioritizes uploading DevID, LatestHash, unconfirmed interval start and end Seq, firmware version, policy version, anomaly flag, and battery level, instead of directly deleting or overwriting local data.

[0120] S8-4 executes a cloud-based challenge response. The cloud returns a random Nonce, and the locator returns an HMAC (Kdev, Nonce ||LatestHash || DevID) or a signature to prevent replay of old data, uploads from fake terminals, or offline forgery.

[0121] S8-5: Evidence frames and trajectory blocks are uploaded in batches. The locator uploads evidence frames, trajectory blocks, and abnormal frames in Seq order. Each batch of uploads is limited by T_tx, number of retries, traffic budget, and power budget.

[0122] S8-6 immediately rolls back upon failure. If network attachment, challenge response, batch upload, or receipt reception fails, the communication module is immediately powered off. The SIM number, PLMN, reason for failure, power-on duration, and retry count of this attempt are written into a new evidence frame.

[0123] S9: Cloud-based evidence chain verification and trajectory consistency check. The process includes:

[0124] S9-1 verifies device identity. The platform verifies the device certificate, shared key index, firmware version, policy version, and asset binding relationship to confirm that the uploaded data comes from a legitimate locator.

[0125] S9-2, recalculate chain authentication values. Starting from the known chain head or the last confirmed position, the platform recalculates the HMAC / signature of each frame in Seq order to check for broken frames, inserted frames, rearranged frames, copied frames, replayed frames, or tampered frames.

[0126] S9-3, Verify RF_OFF consistency. The platform performs rule verification on the RFProof of each evidence frame within the forbidden interval to confirm that RF_EN, Vrf, Irf, RDY, SIM_VCC, TX_inhibit, etc. meet the physical silence conditions.

[0127] S9-4, Verify the consistency of the track summary. The platform calculates the TrackHash of the uploaded track block and compares it with the TrackHash_i in the evidence frame to confirm that the track data has not been replaced, deleted, or removed from the evidence chain.

[0128] S9-5 divides the transportation process into stages, combining trajectory, speed, air pressure, airport fence, and reporting time. The transportation process is divided into storage stage, ground loading and unloading stage, air transport restricted stage, landing waiting stage, ground transportation stage, and uncertain stage.

[0129] S9-6, Generate verification conclusions. The platform outputs the chain continuity, RF_OFF consistency, trajectory consistency, anomaly causes, and compliance conclusions for each interval, and generates exportable report data.

[0130] S10: Receipt processing, compliance report output, and anomaly closure loop. The process is characterized by including:

[0131] S10-1, the platform returns a confirmation receipt. For the range that has passed cloud verification, the platform returns AckStartSeq, AckEndSeq, AckHash, and a signature receipt; for the range that has not passed, no deletion permission is returned.

[0132] S10-2, the device releases the confirmed data. The locator only compresses, deletes, or overwrites the confirmed intervals, while unconfirmed and abnormal intervals are retained to ensure that evidence is not lost due to network anomalies.

[0133] S10-3, Output Silent Compliance Report: The platform generates a report that includes asset number, locator number, flight segment / ground segment, evidence chain start and end sequence number, silent interval, allowed reporting interval, RF anomaly frame, trajectory summary, and cloud verification conclusion.

[0134] S10-4, Abnormal Lockout and Maintenance: If there is a contradictory RF feedback, a broken chain of evidence, an RTC rollback, a storage CRC error, a firmware verification failure, a cloud challenge failure, or a network retry exceeding the limit, the device will remain silent and record the abnormality, waiting for the next security window or manual maintenance.

[0135] S10-5, Security Policy Update: Platform policy updates must be signed by the cloud and are only sent during the short-window communication phase when the release gate is passed; the locator verifies the signature and version and writes it into the policy area, and the update behavior itself also generates an evidence frame.

[0136] like Figure 4 and Figure 5 A compliance tracking system for air cargo locators, employing the aforementioned compliance tracking method for air cargo locators, includes a pre-configuration and self-testing module, a data acquisition and evidence construction module, a communication decision and reporting module, and a cloud verification and closed-loop module;

[0137] The pre-configuration and self-test module is used during the device initialization phase to securely write device keys and identities, initialize the evidence chain head parameters, bind freight assets, pre-configure compliance policies, and perform hardware self-tests.

[0138] The data acquisition and evidence construction module is used to cut off the radio frequency power supply through the hardware latch unit when the device is in default silent state, and after being woken up, it will collect positioning data, sensor summary and radio frequency physical feedback to construct a silent evidence frame containing trajectory summary and preorder hash, and write it to non-volatile memory through chain authentication.

[0139] The communication decision and reporting module is used to power on the communication module within a time limit after confirming that all safety conditions are met through multi-condition logic and judgment of the radio frequency release gate, complete the cloud challenge response and upload data in batches. Once the time limit is exceeded or failure occurs, the power is immediately cut off and the abnormal reason is recorded in the evidence chain.

[0140] The cloud-based verification and closed-loop module is used to verify the integrity of the evidence chain and generate compliance conclusions by recalculating chained authentication values, verifying radio frequency physical feedback and trajectory summaries, returning confirmation receipts to the device, triggering data cleanup and compliance report output, and activating the device's permanent silent locking mechanism when a serious anomaly is detected.

[0141] The data acquisition and evidence construction module includes a low-power monitoring submodule, a trajectory perception submodule, a physical feedback sampling submodule, and an evidence chain construction submodule;

[0142] The low-power monitoring submodule and the physical feedback sampling submodule are used to force the communication module to physically disable using a hardware latch unit, allowing only the RTC and low-power sensors to operate, establishing an RF silence baseline, and monitoring specific wake-up events.

[0143] The trajectory perception submodule is used to collect positioning data, environmental data, and motion status without activating the radio frequency transmission link, and package them to generate a trajectory summary.

[0144] The physical feedback sampling submodule is used to read the RF control commands and physical feedback quantities such as voltage and current on the load side. Through multiple sampling and temperature compensation algorithms, it accurately determines whether the RF module is in a true physical off state.

[0145] The evidence chain construction submodule is used to bind device identity, status data, physical feedback, and preceding hash values, generate tamper-proof chained authentication tags through HMAC or digital signatures, and securely write them to non-volatile memory.

[0146] The silent evidence frame is the core data structure of this invention. Its purpose is not simply to record "the device is in flight," but to bind the radio frequency physical feedback, trajectory summary, and previous frame summary into a verifiable chain. Fields can be tailored according to storage capacity and power consumption requirements.

[0147] Table 1: Field Meaning and Function Table

[0148]

[0149] The authentication value of the i-th evidence frame can be represented as:

[0150] H_i = HMAC(Kdev, DevID || Seq_i || Time_i || SensorDigest_i ||RFProof_i || TrackHash_i || H_{i-1})

[0151] Where Kdev is the device key or the derived key in the security chip, and H_{i-1} is the previous evidence frame digest. If any evidence frame is deleted, inserted, copied, reordered, or modified, the cloud cannot pass when recalculating H_i in sequence.

[0152] Table 2: Table of Key Parameter Ranges

[0153]

[0154] Table 3: Table of Field Name Descriptions

[0155]

[0156] The present invention upgrades "instruction shutdown" to "dual proof of instruction + physical feedback". Existing solutions may only record that the main control has shut down the communication module, but the present invention samples physical quantities that can reflect the transmission ability on the load side or the transmission path and writes them into the evidence frame.

[0157] One determination condition for RF_OFF(i) is as follows:

[0158] RF_OFF(i) = (RF_EN_cmd=0) AND (Vrf<Vth) AND (Irf<Ith) AND (RF_RDY=0)AND (TX_inhibit=1) AND (SIM_VCC=0 or the SIM is in the disabled state)

[0159] Where Vth and Ith can be set according to the communication module specifications, MOS leakage, sampling resistor accuracy, temperature drift, and ADC error. If RF_EN_cmd=0 but Vrf or Irf exceeds the threshold, or RDY indicates that the module is ready, it is determined that there is a feedback contradiction and the device enters abnormal locking. <000​​​The RF release gate is not simply a flight state classifier, but rather a safety permission logic that determines whether the communication module is allowed to power on briefly. Its output, Gate, can be expressed as:

[0162] Gate = C_chain AND C_rf AND C_env AND C_health AND C_window AND C_policy AND C_energy

[0163] If any of the above conditions are unknown, unreliable, or abnormal, the system adopts a "no transmission if unknown" fail-safe strategy. This strategy differs from simply improving the accuracy of flight status identification; its core is to directly transform uncertainty into keeping the radio frequency off and to write the cause of the uncertainty into the chain of evidence.

[0164] After receiving the chain header frame, evidence frame, trajectory data, and anomaly flag uploaded by the locator, the cloud verification platform proceeds according to... Figure 5 Process execution challenge response, chained authentication recalculation, RF_OFF verification, and trajectory consistency verification.

[0165] Taking an air cargo pallet locator as an example, the locator is installed on an air cargo pallet or an air container, acquires its location via GNSS, and transmits data back to the ground safety window via a 4G / 2G dual-SIM cellular network. The locator has a built-in disposable battery, a low-power main control unit, and local memory, and its casing meets the requirements of air cargo environment for impact resistance, dust and water resistance, wide temperature range, and flame retardancy.

[0166] For LR-TX004 type products with four-star positioning, dual SIM and long battery life, an RF security latch unit and load-side feedback sampling can be added between the existing main control and 4G / 2G communication module, or RFProof can be formed by using PMIC, PWR_GOOD / RDY pins of communication module, SIM_VCC detection and UART transmission gating.

[0167] Because the evidence frame only stores the summary, counter, status flag, and authentication code, it does not require continuous GNSS or cellular communication, making it suitable for long-endurance targets. Since the trajectory and evidence chain are uploaded simultaneously, the management platform can display the trajectory and geofence, and also output RF silence compliance results for each transport.

[0168] 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 or improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A compliant tracking method for air cargo locators, characterized in that, Includes the following steps: Step S1: Initialize pre-configuration. During the device initialization phase, the system securely writes the device key and identity, initializes the evidence chain head parameters, binds freight assets, pre-configures compliance policies, and performs hardware self-checks. Step S2: Data acquisition. In the default silent state, the device cuts off the radio frequency power supply through the hardware latch unit, and after being woken up, it collaboratively acquires positioning data, sensor summary and radio frequency physical feedback to construct a silent evidence frame containing trajectory summary and preorder hash, which is then written to non-volatile memory through chain authentication. Step S3: Communication decision and reporting. Through multi-condition logic and judgment of the radio frequency release gate, after confirming that all safety conditions are met, the communication module is powered on within a time limit to complete the cloud challenge response and upload data in batches. Once the timeout or failure occurs, the power is immediately cut off and the cause of the abnormality is recorded in the evidence chain. Step S4: Cloud verification and closed loop. The integrity of the evidence chain is verified by recalculating the chain authentication value, verifying the radio frequency physical feedback and trajectory summary, generating a compliance conclusion, returning a confirmation receipt to the device, triggering data cleanup and compliance report output, and activating the device's permanent silent locking mechanism when a serious anomaly is detected.

2. The air cargo locator compliance tracking method according to claim 1, characterized in that, Step S1 is implemented in the following manner: Write the unique device identity DevID, device certificate or shared key Kdev to the device locator, initialize the monotonic counter Seq_0, initial time Time_0, first frame digest H_0 and policy version PolicyVer, and write the above information to the protected area of ​​non-volatile memory. Bind the locator to the air cargo pallet number, air container number, air waybill number or customer asset number, and write the airworthiness / RF silence policy, including the default prohibition rule, RF_OFF threshold, release gate condition, reporting time window, dual SIM retry budget, abnormal latching level and platform certificate fingerprint. Sequentially check the RF security latch unit, load side voltage / current sampling, communication module RDY / STATUS reading, SIM_VCC detection, UART_TX suppression, non-volatile memory CRC and RTC monotonicity; do not allow entry into communication mode if self-test fails.

3. The compliant tracking method for air cargo locators according to claim 2, characterized in that, Step S2 is implemented in the following manner: Step S21: Default RF silence and low-power listening. After the locator is powered on, the hardware latch unit forces the communication module to enter a physical silence state that does not depend on software initialization. The main control collects the RF feedback, establishes a silence baseline, and immediately locks it when an anomaly is detected. Only the RTC and low-power sensor are allowed to listen to specific trigger events in the continuous silence state of the communication module, so that the evidence chain counter and RTC monotonically increase. Step S22: Wake-up event determination and data acquisition. After the main controller wakes up, it records the trigger source and collects positioning and sensing data without opening the radio frequency transmission link. The relevant information is packaged into a trajectory block and a summary is calculated to bind the evidence frame with the same sequence number. Step S23: RF physical feedback sampling and RF_OFF determination. The main controller reads the RF enable command and the multi-dimensional physical feedback of the load side voltage and current. It performs multiple sampling, temperature compensation and deviation correction on the analog quantity to eliminate glitches and interference. It determines the threshold based on the module specifications and environmental drift for comprehensive determination. If an abnormal power-on or state contradiction is found under the shutdown command, the abnormal flag is immediately set and the lockout state is entered to prohibit short window reporting. Step S24: Silent evidence frame construction, authentication and writing. The evidence frame containing device identity, multi-dimensional status and radio frequency physical feedback is bound with the preceding hash. An anti-tampering chain authentication tag is generated through HMAC or digital signature. A secure writing mechanism is adopted, which first writes the to-submit flag and content, then reads back for verification, and finally updates the submission flag. Step S25: Health check and data retention of the evidence chain. The master controller performs integrity checks on the sequence and time increment, chain head hash and storage CRC. After power failure and restart, it reads the last complete submission frame to generate a recovery frame that records the interruption reason and RTC status. Based on the cloud confirmation status, it securely compresses or deletes the uploaded old intervals, retains unconfirmed data and updates the latest chain head summary, unconfirmed interval start and end Seq and anomaly index.

4. The air cargo locator compliance tracking method according to claim 3, characterized in that, Step S21 is implemented in the following manner: Step S211: Establish default shutdown state. After the locator is powered on, the radio frequency safety latch unit defaults to output shutdown or reset hold, so that the communication module is in a physical power-off, reset hold or transmit prohibition state. Step S212: Acquire silent baseline. The main controller reads the feedback values ​​of RF_EN_cmd, Vrf, Irf, RF_RDY, SIM_VCC, and TX_inhibit to establish silent baseline. If the command is to shut down but there is still abnormal voltage and current on the load side, an abnormal frame is immediately generated and locked. Step S213: Configure the wake-up source, allowing only RTC, low-power acceleration events, loading / unloading shocks, air pressure changes, abnormal power / temperature, maintenance magnetic triggers, or signed maintenance commands to trigger short-term wake-up of the main controller; the cellular communication module must not be used as a normal wake-up source; Step S214: Enter low-power listening mode. The main controller and sensors maintain listening in a low-power state, the communication module remains in a no-send state, and the evidence chain counter and RTC remain monotonically increasing.

5. The air cargo locator compliance tracking method according to claim 3, characterized in that, Step S22 is implemented in the following manner: Step S221: Identify the wake-up reason. After the main controller wakes up, it first records the trigger source. Step S222: Collect positioning and sensing data. Without opening the radio frequency transmission link, collect GNSS coordinates, time, velocity, HDOP, acceleration, air pressure, temperature, battery voltage, estimated battery internal resistance, remaining storage space, and device attitude information. Step S223: Form a track block by packaging one or more positioning points, sensor sampling values ​​and event flags into TrackBlock_i, and calculate TrackHash_i or CRC_i; Step S224: Generate an environmental state summary, obtaining EnvState_i based on speed, air pressure change, GNSS effectiveness, motion duration, airport geofencing, and historical flight path rules.

6. The air cargo locator compliance tracking method according to claim 3, characterized in that, Step S23 is implemented in the following manner: Step S231: Read the instruction status and physical feedback. The main controller reads RF_EN_cmd, load-side voltage Vrf, load-side current Irf, communication module gating status, module reset pin, baseband wake-up pin, and optional external comparator output. Step S232: Perform filtering and threshold compensation. Perform multiple sampling, temperature compensation, ADC deviation correction and glitch filtering on the Vrf / Irf analog quantity. The thresholds Vth and Ith are determined according to the communication module specifications, MOS leakage current, sampling resistor error and temperature drift. Step S233: Calculate and process feedback contradictions, calculate RF_OFF conditions, and the main controller comprehensively determines RF_OFF based on multi-dimensional conditions such as RF enable, voltage and current thresholds, ready state and SIM card status. When a contradiction between the instruction and physical feedback is detected, the RF credibility is set to zero, the cause of the anomaly is recorded, the latching mechanism is triggered, and the short window reporting is blocked.

7. The air cargo locator compliance tracking method according to claim 1, characterized in that, Step S3 is implemented in the following manner: Step S31: Radio frequency release gate determination. In the radio frequency release gate determination stage, strict multi-condition logic AND operation is performed on the continuity of the evidence chain, radio frequency physical silence feedback, ground safety environment, equipment health status, reporting time window, strategy effectiveness and energy reserve to output a permission signal. Following the fail-safe principle, any unknown or abnormal state is judged as a prohibition on transmission by default. Step S32: Short window communication, dual SIM selection and controlled reporting. After the release door is opened, timed power-on and network selection are performed. After verifying the identity through challenge response, the chain head and status are uploaded first, and then evidence frames and trajectory data are reported in batches in sequence. If network failure or timeout occurs, power is cut off and the reason for failure is recorded in the evidence chain.

8. The air cargo locator compliance tracking method according to claim 1, characterized in that, Step S4 is implemented in the following manner: Step S41: Cloud-based evidence chain verification and trajectory consistency verification. The cloud verifies data integrity by recalculating the chain authentication value, cross-verifies the consistency between radio frequency physical feedback and trajectory summary, confirms that there was no illegal transmission during flight, and generates a closed-loop judgment conclusion on compliance or abnormality based on this. Step S42: Receipt processing, compliance report output and anomaly closure. After returning the start and end sequence numbers of the verified data, the platform deletes or compresses the confirmed data and outputs a compliance report containing the silent period, reporting period and anomaly cause. If there is a broken evidence chain or serious anomaly due to physical feedback contradictions, permanent silent closure will be triggered until manual maintenance.

9. An air cargo locator compliance tracking system, employing the air cargo locator compliance tracking method as described in any one of claims 1-8, characterized in that, It includes a pre-configuration and self-testing module, a data acquisition and evidence construction module, a communication decision and reporting module, and a cloud verification and closed-loop module; The pre-configuration and self-test module is used during the device initialization phase to securely write device keys and identities, initialize the evidence chain head parameters, bind freight assets, pre-configure compliance policies, and perform hardware self-tests. The data acquisition and evidence construction module is used to cut off the radio frequency power supply through the hardware latch unit when the device is in default silent state, and after being woken up, it will collect positioning data, sensor summary and radio frequency physical feedback to construct a silent evidence frame containing trajectory summary and preorder hash, and write it to non-volatile memory through chain authentication. The communication decision and reporting module is used to power on the communication module within a time limit after confirming that all safety conditions are met through multi-condition logic and judgment of the radio frequency release gate, complete the cloud challenge response and upload data in batches. Once the time limit is exceeded or failure occurs, the power is immediately cut off and the abnormal reason is recorded in the evidence chain. The cloud-based verification and closed-loop module is used to verify the integrity of the evidence chain and generate compliance conclusions by recalculating chained authentication values, verifying radio frequency physical feedback and trajectory summaries, returning confirmation receipts to the device, triggering data cleanup and compliance report output, and activating the device's permanent silent locking mechanism when a serious anomaly is detected.

10. The air cargo locator compliance tracking system according to claim 9, characterized in that, The data acquisition and evidence construction module includes a low-power monitoring submodule, a trajectory perception submodule, a physical feedback sampling submodule, and an evidence chain construction module; The low-power monitoring submodule and the physical feedback sampling submodule are used to force the communication module to physically disable using a hardware latch unit, allowing only the RTC and low-power sensors to operate, establishing an RF silence baseline, and monitoring specific wake-up events. The trajectory perception submodule is used to collect positioning data, environmental data, and motion status without activating the radio frequency transmission link, and package them to generate a trajectory summary. The physical feedback sampling submodule is used to read the RF control commands and physical feedback quantities such as voltage and current on the load side. Through multiple sampling and temperature compensation algorithms, it accurately determines whether the RF module is in a true physical off state. The evidence chain construction submodule is used to bind device identity, status data, physical feedback and preceding hash value, generate tamper-proof chain authentication tags through HMAC or digital signature, and securely write them to non-volatile memory.

Images