An off-line instruction caching method for an unmanned vehicle based on a Beidou short message

Abstract

The present application relates to the technical field of unmanned vehicle instruction cache, and particularly relates to an unmanned vehicle offline instruction cache method based on a Beidou short message, which comprises the following steps: actively reporting a local effective serial number and a request version number in a receivable window through the unmanned vehicle side, so that the service center can know which instruction has been executed by the unmanned vehicle and the instruction version, thereby accurately excluding the effective, expired or version-lagged instructions in the differential calculation, and avoiding repeated issuance or issuance of invalid instructions; meanwhile, the unmanned vehicle side screens the instruction entries according to the semantic conflict labels between the instructions when executing the gate, obtains a set of unexecuted instructions and feeds back to the service center, and the service center invalidates and propagates the entries in the offline instruction pool which have semantic mutual exclusion relationship with the rejected instructions, thereby eliminating the risk of execution error caused by semantic contradiction between the instructions, and solving the problem of insufficient instruction effectiveness guarantee caused by the inability to perceive the unmanned vehicle instruction execution state and the semantic relationship between the instructions.

Description

Technical Field

[0001] This invention relates to the field of unmanned vehicle command caching technology, specifically to an offline command caching method for unmanned vehicles based on BeiDou short message service. Background Technology

[0002] BeiDou short message communication, with its advantages of not being limited by terrestrial network coverage, having wide coverage and being autonomously controllable, has become an important backup communication method for unmanned vehicles to obtain remote control commands when performing tasks in remote areas, disaster sites, or communication blind spots.

[0003] However, BeiDou short message communication has inherent constraints such as limited frequency, extremely small single packet capacity, and no native delivery receipt. Therefore, ground control centers usually adopt an offline command caching method, temporarily storing the commands to be issued in the service center, and then sending them one by one or in batches via short messages when the BeiDou terminal of the unmanned vehicle becomes available.

[0004] Currently, the common approach is for the service center to maintain a first-in-first-out (FIFO) or fixed-priority queue. Within the allowed transmission rhythm of BeiDou short messages, instructions are retrieved from the queue sequentially or sent packet by packet, with the unmanned vehicle (UAV) passively receiving and executing them sequentially. While this method can achieve basic instruction transmission in simple scenarios, it severely undermines the guarantee of instruction validity. Because the service center cannot know which instructions the UAV has actually executed, which instructions were lost or only partially arrived during transmission due to link interruptions, which instructions have exceeded their allowed execution time due to long queuing periods, or whether there are semantic exclusions or conflicts between multiple instructions, the UAV is highly prone to executing expired instructions, instructions contradicting the current task status, repeatedly executing effective instructions, or having the service center repeatedly resend the same instructions due to a lack of feedback on executed instructions. This not only wastes extremely valuable BeiDou short message communication resources but also poses a direct threat to the safe operation of the UAV by executing instructions that should not be executed. Summary of the Invention

[0005] To address the technical problem of insufficient guarantee of instruction validity caused by the inability to perceive the execution status of instructions on the autonomous vehicle side and the semantic relationship between instructions, this application provides an offline instruction caching method for autonomous vehicles based on Beidou short messages.

[0006] The offline command caching method for unmanned vehicles based on BeiDou short message service provided in this application adopts the following technical solution: An offline command caching method for unmanned vehicles based on BeiDou short message service includes: The instructions to be executed that arrive at the autonomous vehicle are written into the offline instruction pool of the autonomous vehicle in the form of preset instructions to obtain the set of instructions to be issued. Within the receiver window of the detected BeiDou terminal, a pull request is constructed based on the historical data of the unmanned vehicle. The pull request includes the unmanned vehicle identifier, the request effective sequence number, the request version number, and the receiver capability budget. Based on the BeiDou short message uplink, after the pull request is sent to the service center, the service center performs differential calculation on the set of instructions to be issued based on the request effective sequence number and request version number to obtain the candidate differential set, and then calculates the differential payload based on the candidate differential set. The candidate difference sets are sorted in ascending order according to the preset instruction sequence number and packed under the constraint of the receiving capability budget. After obtaining the response packet, the response packet is sent to the unmanned vehicle through the Beidou short message downlink. The differential payload is parsed based on the response packet to obtain the instruction entries. Then, the execution gating is performed according to the instruction entries to obtain the execution result sequence, the locally updated effective sequence number, and the set of unexecuted instructions. The offline command pool is trimmed based on the locally updated effective sequence number, and commands in the offline command pool are invalidated based on the unexecuted command sets, resulting in the updated offline command pool.

[0007] Furthermore, the steps of writing the pending instructions to the autonomous vehicle into the autonomous vehicle's offline instruction pool in the form of preset instructions to obtain the set of instructions to be issued include: Based on the arrival order of each instruction to be executed, assign each instruction to an instruction sequence number that monotonically increases in the order of arrival to obtain the first instruction to be executed; Based on the generation time of the first instruction to be executed and the preset validity period, the validity period of the first instruction to be executed is calculated to obtain the second instruction to be executed; Generate a semantic conflict label corresponding to the second instruction to be executed, and assign it to the corresponding second instruction to be executed to obtain the third instruction to be executed; After converting the instruction identifier, instruction content, instruction sequence number, instruction version number, validity period, and semantic conflict tag of each third instruction to be executed into structured fields, they are written into the offline instruction pool to obtain the set of instructions to be issued.

[0008] Furthermore, the steps of constructing a pull request based on historical data of the unmanned vehicle within the detected receivable window of the Beidou terminal include: After obtaining the time point when the BeiDou terminal completes the entry lock and the signal strength exceeds the preset signal strength, the time point is used as the starting time of the receptive window; Start the timer based on the initial time; During the timer's operation, the system reads the historical instruction sequence number of the historical executed instructions stored locally on the autonomous vehicle as the request effective sequence number, reads the historical instruction version number received by the autonomous vehicle from the service center as the request version number, and obtains the upper limit value of the receiveable window as the receive capability budget. Then, it constructs a pull request including the autonomous vehicle identifier, the request effective sequence number, the request version number, and the receive capability budget.

[0009] Furthermore, the steps for calculating the difference between the set of instructions to be issued based on the request's effective sequence number and request version number at the service center, and obtaining the candidate difference set, include: Select the instruction to be issued from the set of instructions to be issued, and select the instruction to be issued whose instruction sequence number is greater than the request effective sequence number and whose instruction version number is greater than the request version number as the first instruction to be issued; Based on the current time, select the first pending instruction that is within the validity period from all the first pending instructions as the second pending instruction; Based on the semantic conflict tags of each second instruction to be issued, the second instruction to be issued corresponding to the instruction sequence number in the first order is obtained from the second instructions to be issued belonging to the same mutually exclusive category, and the candidate difference set is obtained.

[0010] Furthermore, the steps for calculating the differential load based on the candidate difference set include: Based on the instruction sequence number of each candidate instruction in the candidate difference set, the candidate instructions are sorted in ascending order of instruction sequence number to obtain the sorted candidate difference set; Based on the sorted candidate difference set, the payload length of each candidate instruction is accumulated sequentially until the first accumulation result exceeds the receiver capability budget. The candidate instructions corresponding to the first accumulation result are then determined as the instruction set to be calculated. Based on the payload content corresponding to each instruction in the instruction set to be calculated, the starting offset position of each instruction to be calculated and the instruction length of each instruction to be calculated are determined. Then, the starting offset position and the instruction length are added to the sorted candidate difference set to obtain the index table. Fill the load content of each instruction to be calculated into the index table to obtain the differential load.

[0011] Furthermore, the steps for packing the response packet under the constraint of the receiving capacity budget include: The lightweight check value is calculated based on the payload bytes of the differential payload, the request effective sequence number and the request version number in the pull request; Generate the header fields of the response packet based on the request effective sequence number and the request version number; The differential payload, lightweight checksum, and header fields are concatenated according to the frame format of BeiDou short messages to obtain the response packet.

[0012] Furthermore, the steps for parsing the differential load based on the response packet to obtain the instruction entries include: Based on the lightweight check value, integrity checks are performed on the header field and differential payload to obtain the checked header field and the checked differential payload. Based on the starting offset position and instruction length of each instruction to be calculated in the response packet, the differential load after cutting and verification is used to obtain the load content of each instruction to be calculated. Based on the instruction sequence number of each instruction to be calculated and the verified header field, complete the payload content to obtain the complete instruction sequence number, and combine the complete instruction sequence number with the instruction identifier and instruction content in the payload content to obtain instruction entries arranged according to the complete instruction sequence number.

[0013] Beneficial effects achieved: This application provides an offline command caching method for unmanned vehicles based on BeiDou short message service, comprising: writing the commands to be executed arriving at the unmanned vehicle into the unmanned vehicle's offline command pool in a preset command format to obtain a set of commands to be issued; constructing a pull request based on the unmanned vehicle's historical data within the detected receive window of the BeiDou terminal, wherein the pull request includes the unmanned vehicle identifier, the request's effective sequence number, the request version number, and the receive capability budget; sending the pull request to the service center based on the BeiDou short message uplink, and performing differential calculation on the set of commands to be issued at the service center based on the request's effective sequence number and the request version number. After obtaining the candidate difference set, the differential payload is calculated based on the candidate difference set; the candidate difference set is sorted in ascending order according to the preset instruction sequence number and boxed under the constraint of the receiving capability budget to obtain the response packet, and then sent to the unmanned vehicle through the Beidou short message downlink; the differential payload is parsed according to the response packet to obtain the instruction entries, and then the execution gating is performed according to the instruction entries to obtain the execution result sequence, the locally updated effective sequence number, and the unexecuted instruction set; the offline instruction pool is pruned according to the locally updated effective sequence number, and the instructions in the offline instruction pool are invalidated according to the unexecuted instruction set to obtain the updated offline instruction pool.

[0014] In this application, the autonomous vehicle proactively reports its local effective sequence number and requested version number within the receiving window, enabling the service center to accurately know which instruction the autonomous vehicle has executed and the instruction set version status. This allows for precise exclusion of effective, expired, or outdated instructions during differential calculation, avoiding duplicate or invalid instruction issuance. Simultaneously, during gating, the autonomous vehicle filters instruction entries based on semantic conflict tags, obtaining unexecuted instruction sets and feeding them back to the service center. The service center then invalidates and propagates entries in the instruction pool that have semantic mutual exclusion relationships with rejected instructions, eliminating the risk of execution errors due to semantic contradictions between instructions. Through this two-way state perception and feedback loop, the service center can maintain a consistent view of instruction effectiveness with the autonomous vehicle, fundamentally solving the problem of insufficient instruction validity assurance caused by the inability to perceive the instruction execution status and semantic relationships between instructions on the autonomous vehicle side. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the steps of an offline command caching method for unmanned vehicles based on BeiDou short messages, as proposed in this application. Figure 2 A flowchart illustrating the steps involved in generating the set of instructions to be issued for this application; Figure 3 A flowchart illustrating the steps involved in constructing a pull request for this application; Figure 4 This is a flowchart illustrating the steps involved in calculating the differential load based on the candidate difference set after obtaining it in this application. Figure 5 A flowchart illustrating the steps involved in generating a response package for this application; Figure 6 This is a flowchart illustrating the steps involved in parsing the differential load to obtain instruction entries in this application. Detailed Implementation

[0016] The following combination Figures 1 to 6 This application will be described in further detail.

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

[0018] It should be noted that if the embodiments of the present invention involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative positional relationship and movement of the components in a specific posture. If the specific posture changes, the directional indications will also change accordingly.

[0019] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the use of "and / or" or "and / or" throughout the text includes three parallel solutions. For example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0020] This application discloses an offline command caching method for unmanned vehicles based on BeiDou short message service.

[0021] Please refer to Figure 1 The offline command caching method for unmanned vehicles based on BeiDou short message service proposed in this embodiment includes steps S10 to S60: Step S10: Write the pending instructions to the autonomous vehicle into the offline instruction pool of the autonomous vehicle in the form of preset instructions to obtain the set of instructions to be issued.

[0022] The pending instructions arriving at the autonomous vehicle are written into the vehicle's offline instruction pool in a preset instruction format. This process transforms each pending instruction into a structured combination of fields, including instruction identifier, instruction content, instruction sequence number, instruction version number, validity period, and semantic conflict tag. This forms a searchable, sortable, and comparable set of pending instructions, allowing the service center to no longer treat pending instructions as isolated message objects. Instead, these instructions are incorporated into a unified management framework with version information and semantic attributes. This provides the data prerequisite for subsequent differential calculations based on the request validity sequence number and request version number fed back from the autonomous vehicle, thereby preventing the duplicate issuance of valid instructions and the erroneous issuance of expired instructions from the source, laying the data foundation for ensuring the validity of instructions.

[0023] Step S20: Within the receivable window of the detected Beidou terminal, a pull request is constructed based on the historical data of the unmanned vehicle. The pull request includes the unmanned vehicle identifier, the request effective sequence number, the request version number, and the receiving capability budget.

[0024] The timing of command issuance has been changed from one-way timed push from the service center to active state-driven retrieval by the autonomous vehicle, thereby solving the problem of invalid command issuance caused by the service center's inability to know the actual execution progress of the autonomous vehicle.

[0025] By constructing a pull request based on historical data from the unmanned vehicle (UAV) within the detected receive window of the BeiDou terminal, the system allows the UAV to proactively report its key status information to the service center during the brief communication window of the BeiDou terminal. This information includes the UAV identifier, the request activation sequence number, the request version number, and the receive capacity budget. The request activation sequence number indicates which instruction the UAV has executed, the request version number indicates the instruction set version currently held by the UAV, and the receive capacity budget indicates the maximum amount of data the UAV can receive within the current receive window. Upon receiving the pull request, the service center can understand the UAV's execution status and receive capacity. Therefore, in subsequent steps, it only sends the differential payload that the UAV has not yet executed and that is updated in version, and it controls the amount of data sent within the UAV's current receive capacity. This fundamentally avoids repeatedly sending activated instructions, sending outdated instructions, and sending data exceeding the receive capacity, resulting in packet loss. This ensures that every BeiDou short message transmission serves the truly needed and valid instructions, significantly improving the efficiency of limited communication resources and the accuracy of instruction delivery.

[0026] Step S30: Based on the BeiDou short message uplink, after the pull request is sent to the service center, the service center performs differential calculation on the set of instructions to be issued based on the request effective sequence number and request version number, obtains the candidate differential set, and then calculates the differential payload based on the candidate differential set.

[0027] By utilizing the request validity sequence number and request version number proactively reported by the autonomous vehicle, the service center can filter the set of instructions to be issued, thereby eliminating the waste of communication resources and loss of instruction validity caused by blind issuance.

[0028] After the pull request is sent to the service center based on the BeiDou short message uplink, the service center performs differential calculation on the set of instructions to be issued based on the request effective sequence number and the request version number. The purpose is to remove instructions that the unmanned vehicle has already executed based on the request effective sequence number as the lower limit, and to remove old version instructions that the unmanned vehicle already holds or that have expired based on the request version number, retaining only instructions that the unmanned vehicle has not yet obtained and that have been updated, thus obtaining the candidate difference set.

[0029] Subsequently, the differential payload is calculated based on the candidate difference set. Its function is to arrange multiple candidate instructions in the candidate difference set in ascending order of instruction sequence number, and then compactly package them under the constraint of the receiving capacity budget to form a differential payload that can be sent in a single BeiDou short message. This allows the service center to no longer blindly push the entire instruction queue one by one, but only send the differential instructions that the unmanned vehicle is missing and that are currently valid. Furthermore, these differential instructions are compressed into a single packet that can be carried by the payload. This achieves the accuracy, efficiency and non-redundancy of instruction sending within the extremely limited BeiDou communication bandwidth, and significantly reduces the communication overhead and execution risk caused by repeated or expired instruction sending.

[0030] The process of sending a pull request to the service center based on the BeiDou short message uplink is as follows: After detecting the receptive window of the BeiDou terminal, the unmanned vehicle (UAV) formats and encapsulates the pre-constructed pull request data according to the BeiDou short message communication protocol. This involves adding the frame header required for BeiDou communication, the target address (the address of the BeiDou command unit or designated receiving terminal at the service center), the source address (the address of the UAV's own BeiDou terminal), the communication frequency identifier, and a verification field to the data front end, forming a data frame that meets the upper limit of the BeiDou short message single packet length. Subsequently, the UAV's BeiDou terminal transmits this data frame via its radio frequency module on the uplink frequency of the BeiDou satellite. The data frame is transparently forwarded by the BeiDou satellite to the BeiDou command unit or BeiDou data receiving gateway at the ground center station. After the receiving equipment at the ground center station completes signal acquisition, demodulation, decoding, and verification, it reconstructs the UAV identifier, request validity sequence number, request version number, and receiving capacity budget from the pull request and passes it to the service center's business processing module for subsequent steps.

[0031] Step S40: The candidate difference sets are sorted in ascending order according to the preset instruction sequence number and packed under the constraint of the receiving capability budget. After obtaining the response packet, the response packet is sent to the unmanned vehicle through the Beidou short message downlink.

[0032] This step ensures that the instructions issued by the service center strictly follow the expected execution order on the unmanned vehicle side in terms of timing, while strictly controlling the amount of data transmitted in a single BeiDou short message within the unmanned vehicle's declared receiving capacity budget, in order to avoid parsing failures or execution errors caused by out-of-order instructions or data overload.

[0033] The candidate difference set is sorted in ascending order according to the preset instruction sequence number. This ensures that the order of multiple instructions in the response packet is consistent with the order in which they were generated, so that the unmanned vehicle can execute them in the correct logical order after subsequent parsing, preventing the task status from being confused due to disordered instructions.

[0034] Packing is performed under the constraint of receiving capacity budget, so that the candidate command payloads that meet the order requirements in the candidate difference set are compactly encapsulated into a single response packet that does not exceed the maximum data volume that the unmanned vehicle can receive at this time. This ensures that the response packet can be transmitted completely in one BeiDou short message without being truncated or discarded. After receiving the response packet, it is sent to the unmanned vehicle through the BeiDou short message downlink. Its function is to reliably deliver the encapsulated command data to the BeiDou terminal of the unmanned vehicle by utilizing the broadcast or point-to-point transmission capability of BeiDou satellites. This allows the unmanned vehicle to directly parse and execute the response packet without additional reassembly or waiting after receiving it. Moreover, because the command order is correct and the data volume is appropriate, the risk of command failure caused by link layer packet loss or application layer out-of-order delivery is greatly reduced. Thus, efficient, orderly and reliable command delivery is achieved under the dual constraints of BeiDou short message frequency and capacity.

[0035] The process of sorting the candidate difference set in ascending order of preset instruction sequence numbers involves: extracting the instruction sequence number carried by each candidate instruction from the candidate difference set. This instruction sequence number is a unique integer identifier assigned by the service center when the instruction is generated and monotonically increases with the order of arrival. Then, using this instruction sequence number as the sorting key, a stable sorting algorithm (such as merge sort or quick sort) is used to compare and rearrange all candidate instructions in the candidate difference set, so that instructions with smaller instruction sequence numbers are placed first and instructions with larger instruction sequence numbers are placed later. Finally, the sorted candidate instruction sequence is used as the input for subsequent bin packing operations to ensure that the order of instructions in the response packet strictly follows the ascending order of sequence numbers.

[0036] After generating the response packet, the specific steps for sending the response packet to the unmanned vehicle via the BeiDou short message downlink are as follows: After the service center completes the encapsulation of the response packet, it submits the response packet to the BeiDou command unit or BeiDou data transmission gateway at the ground center station; the ground transmission equipment formats the response packet according to the BeiDou short message communication protocol, that is, it adds the BeiDou frame synchronization code, the target address (the address of the unmanned vehicle's BeiDou terminal), the source address (the address of the service center's BeiDou command unit), the communication frequency identifier, and the downlink check field to the header of the response packet, forming a downlink data frame that meets the upper limit of the BeiDou short message single packet length; then the ground transmission equipment transmits the downlink data frame on the downlink frequency of the BeiDou satellite through its radio frequency module. The downlink data frame is received by the BeiDou satellite and transparently forwarded to the downlink channel within the beam coverage area of ​​the unmanned vehicle; the BeiDou terminal of the unmanned vehicle maintains the receiving state within the receiving window. When the satellite signal arrives, the terminal completes the signal acquisition, synchronization, demodulation, and channel decoding, and extracts the response from the decoded data frame.

[0037] Step S50: Parse the differential payload according to the response packet to obtain the instruction entries, and then perform execution gating according to the instruction entries to obtain the execution result sequence, the locally updated effective sequence number, and the set of unexecuted instructions.

[0038] The differential payload issued by the service center is restored into executable instruction entries, and an execution gating mechanism is used to ensure that only valid and semantically compatible instructions are actually executed, thereby eliminating the security risks caused by executing expired or conflicting instructions.

[0039] The differential payload is parsed based on the response packet. Its function is to extract the index table from the differential payload, and cut out the payload content of each instruction to be calculated based on the starting offset position and its own length recorded in the index table. Then, it combines the instruction sequence number in the response packet header to complete the complete instruction sequence number of each instruction to be calculated, thereby obtaining the instruction entries arranged by instruction sequence number.

[0040] The execution gating based on instruction entries checks the validity period and semantic conflict label of each instruction to be calculated. Instructions that have not expired and do not conflict with the current autonomous vehicle task status are executed, while expired or semantically conflicting instructions are rejected and recorded. This results in an execution result sequence, locally updated effective sequence numbers, and a set of unexecuted instructions. This ensures that the autonomous vehicle only executes truly valid and safe instructions, avoiding the execution of expired instructions due to link delays or task status chaos due to contradictions between instructions. At the same time, the locally updated effective sequence numbers reflect the actual location of the autonomous vehicle, and the set of unexecuted instructions records the rejected instructions and their reasons. This provides an accurate basis for subsequent steps to report the execution status to the service center and guide instruction pool trimming, thus building an execution defense line for the validity and safety of instructions on the autonomous vehicle side.

[0041] The specific process of gating the execution based on instruction entries to obtain the execution result sequence, locally updated effective sequence numbers, and unexecuted instruction sets is as follows: First, the autonomous vehicle extracts the parsed instruction entries one by one in ascending order of instruction sequence number, and performs the following gating checks on each instruction entry: Step 1: Extract the validity period of the instruction entry, compare the current local clock time of the autonomous vehicle with the validity period. If the current time has exceeded the validity period, the instruction entry is determined to be expired, marked as "expired," and added to the unexecuted instruction set, while recording the rejection reason as "expired." Step 2: If the instruction entry has not expired, extract the semantic conflict label of the instruction entry, compare the semantic conflict label with the task status label currently being executed by the autonomous vehicle, and if the two belong to the same mutually exclusive category and there is already an instruction of the same category being executed, or If an instruction has already been executed, it is determined that the instruction entry has a semantic conflict, and it is marked as "semantic conflict exists" and added to the set of unexecuted instructions. At the same time, the rejection reason is recorded as "conflict with the current task state". In the third step, for instruction entries that pass both the validity period check and the semantic conflict check, they are submitted to the execution engine of the autonomous vehicle for sequential execution, and the instruction sequence number of the instruction entry is recorded in the list of executed instructions. In the fourth step, after all instruction entries have completed the above gating process, the largest instruction sequence number is taken from the list of executed instructions as the local update effective sequence number. Each instruction in the list of executed instructions and its execution result (success or failure) are combined into an execution result sequence. The instruction sequence number and rejection reason of each rejected instruction in the set of unexecuted instructions are also packaged together to obtain the execution result sequence, the local update effective sequence number, and the set of unexecuted instructions.

[0042] Step S60: The offline instruction pool is trimmed according to the locally updated effective sequence number, and the instructions in the offline instruction pool are invalidated according to the unexecuted instruction set to obtain the updated offline instruction pool.

[0043] This ensures that the offline command pool on the service center side is precisely consistent with the actual execution status on the autonomous vehicle side, thereby completely eliminating the potential risks of duplicate command issuance, invalid residues, or semantic conflicts caused by information asynchrony between the service center and the autonomous vehicle.

[0044] The offline command pool is pruned based on the locally updated effective sequence number. This removes all command entries in the offline command pool whose sequence number is not greater than the locally updated effective sequence number, as these command entries have already been confirmed and executed by the autonomous vehicle and no longer need to be retained or reissued. The offline command pool is also invalidated based on the set of unexecuted commands. This marks or deletes the entry corresponding to the command sequence number of each rejected command in the set of unexecuted commands. Furthermore, other command entries in the offline command pool that have a semantically mutually exclusive relationship with the rejected command are also invalidated, thereby preventing commands with semantic conflicts from remaining in the pool and being incorrectly issued in the future. The effect of this approach is that the offline command pool, after being pruned and invalidated, retains only valid commands that the autonomous vehicle has not yet executed, has not expired, and can be independently issued semantically. When the service center receives a new fetch request, it can recalculate the differential based on this updated offline command pool, ensuring that each issued command is one that the autonomous vehicle truly needs and can safely execute. This forms a complete closed loop from autonomous vehicle status reporting, service center differential calculation, command issuance, execution gating to command pool updates, fundamentally guaranteeing the command validity, timeliness, and semantic consistency of the BeiDou short message-based autonomous vehicle offline command caching method.

[0045] Specifically, the process of pruning the offline command pool based on the locally updated effective sequence number is as follows: First, the service center extracts the locally updated effective sequence number returned by the autonomous vehicle from the received minimal confirmation information. This locally updated effective sequence number represents the highest command sequence number confirmed to be executed by the autonomous vehicle. Then, it iterates through all command entries in the offline command pool, comparing the command sequence number of each command with the locally updated effective sequence number. Command entries with command sequence numbers not greater than the locally updated effective sequence number are deleted from the offline command pool, as these command entries have already been confirmed and executed by the autonomous vehicle and no longer need to be retained or reissued. Simultaneously, the process of invalidating commands in the offline command pool based on the unexecuted command set is as follows: The command sequence number of each rejected command entry is extracted from the unexecuted command set. The command entry corresponding to this command sequence number is found in the offline command pool and marked as "invalidated" or directly deleted to prevent the command entry from being reissued in the future.

[0046] In addition, for the semantic conflict label carried by each rejected instruction entry in the unexecuted instruction set, all other instruction entries belonging to the same mutually exclusive category as the semantic conflict label are searched in the offline instruction pool. These instruction entries with semantic mutual exclusion are also marked as "invalid" or deleted, thereby completely eliminating the potential for execution errors caused by semantic contradictions between instructions.

[0047] After the above-mentioned trimming and invalidation operations, the offline instruction pool retains only valid instructions that have not yet been executed by the autonomous vehicle, have not expired, and can be issued independently in terms of semantics, thus obtaining the updated offline instruction pool.

[0048] In one feasible implementation, refer to Figure 2 As shown, step S10 may specifically include steps S11 to S14: Step S11: Based on the arrival order of each instruction to be executed, assign each instruction to be executed a monotonically increasing instruction sequence number according to the arrival order to obtain the first instruction to be executed.

[0049] It should be noted that the pending instruction refers to the specific operation command generated by the ground control center and prepared to be sent to the unmanned vehicle via Beidou short message, such as path change, speed adjustment, mission abort, etc.; the instruction sequence number is an integer number assigned to each pending instruction. This number strictly increases monotonically according to the order in which the pending instructions arrive at the service center, that is, the instruction sequence number obtained by the pending instruction that arrives later must be greater than that of the pending instruction that arrives earlier.

[0050] The specific allocation process is as follows: When an instruction to be executed arrives at the offline instruction cache system of the service center, the maximum instruction sequence number currently allocated is read first (the initial value is zero or a preset starting value). Then, the maximum instruction sequence number is incremented by one to become the instruction sequence number of the new instruction to be executed. The instruction sequence number is then bound to the arrival timestamp of the instruction to be executed. If multiple instructions to be executed arrive at the same time, the incremental instruction sequence numbers are allocated sequentially according to the internal processing order of the system, thereby ensuring that each instruction to be executed obtains a unique instruction sequence number that strictly reflects the order of arrival, thus obtaining the first instruction to be executed.

[0051] By assigning each pending instruction a sortable and comparable globally unique identifier (i.e., instruction sequence number), the service center can determine which pending instructions have been executed by the autonomous vehicle based on the instruction sequence number in subsequent steps. This allows for the exclusion of already effective pending instructions during differential calculation, and the issuance of only pending instructions that the autonomous vehicle has not yet received. This fundamentally avoids duplicate issuance or instruction omissions, providing the most basic sequential basis for ensuring the validity of instructions.

[0052] Step S12: Based on the generation time of the first instruction to be executed and the preset validity period, calculate the validity period of the first instruction to be executed to obtain the second instruction to be executed.

[0053] It should be noted that the preset validity period refers to the maximum time span allowed for each first instruction to be executed from the time it is generated until it expires. This preset validity period is preset by the type of the first instruction to be executed or the task requirements. For example, the preset validity period of an emergency stop instruction is shorter to ensure timely response, while the preset validity period of a regular navigation instruction is longer to accommodate normal transmission delays. The validity period refers to the specific deadline when the first instruction to be executed expires. Instructions that exceed this deadline are considered expired and should not be executed.

[0054] Once the first instruction to be executed is assigned an instruction sequence number, the generation time of the first instruction to be executed (i.e., the timestamp when the instruction arrives at the service center and is written to the offline instruction pool) is recorded. Then, the corresponding preset validity period is read from the attribute configuration or instruction type mapping table of the first instruction to be executed. The generation time is added to the preset validity period to obtain an absolute time value as the validity period of the first instruction to be executed. This validity period is then appended to the corresponding first instruction to be executed to obtain the second instruction to be executed.

[0055] For example, if the first instruction to be executed is generated at 10:00:00 on a certain day, and its preset validity period is 600 seconds, then the calculated validity period is 10:10:00 on that day. This sets a clear expiration boundary for each instruction, enabling the unmanned vehicle to accurately identify and refuse to execute expired instructions by comparing the current time with the validity period when performing gating. This fundamentally prevents the security risks of instructions being incorrectly executed after they have expired due to delays in BeiDou short message transmission or long queues of instructions in the buffer queue.

[0056] Step S13: Generate a semantic conflict tag corresponding to the second instruction to be executed, and assign it to the corresponding second instruction to be executed to obtain the third instruction to be executed.

[0057] It should be noted that the semantic conflict label is a classification tag used to identify the mutual exclusion category to which the second instruction to be executed belongs. Its function is to group instructions with the same operation object or the same control dimension into the same mutual exclusion group, so that different instructions in the same group cannot take effect or be executed at the same time.

[0058] When the second instruction to be executed enters the preprocessing stage before entering the offline instruction pool, the instruction type field of the second instruction to be executed is first parsed, such as "navigation point change", "speed adjustment", "task abort", "emergency stop", "sensor parameter setting", etc. Then, according to the preset instruction type and semantic conflict label mapping table, a fixed semantic conflict label is assigned to each instruction type. For example, all instructions involving autonomous vehicle motion trajectory control (such as navigation point change, path planning update) are assigned the label "motion control", all instructions involving task state switching (such as task abort, task restart) are assigned the label "task switching", and all instructions involving safety intervention (such as emergency stop, emergency avoidance) are assigned the label "safety control". If an instruction involves multiple mutually exclusive dimensions, the most important dimension is taken or a comprehensive label is assigned. After the mapping is completed, the semantic conflict label is attached to the corresponding second instruction to be executed as a field to generate the third instruction to be executed.

[0059] For example, a second instruction to be executed, "Navigation point change," is assigned the semantic conflict label "motion control," and a second instruction to be executed, "emergency stop," is assigned the semantic conflict label "safety control." This provides the autonomous vehicle with a clear basis for semantic mutual exclusion judgment when performing gating, enabling the autonomous vehicle to identify and prevent the simultaneous execution of multiple instructions belonging to the same mutually exclusive category but with contradictory content (such as two different target point instructions belonging to the "motion control" category). This fundamentally prevents the autonomous vehicle's task state from becoming chaotic or dangerous due to semantic conflicts between instructions, ensuring the logical consistency and safety of instruction execution.

[0060] Step S14: Convert the instruction identifier, instruction content, instruction sequence number, instruction version number, validity period and semantic conflict tag of each third instruction to be executed into structured fields and write them into the offline instruction pool to obtain the set of instructions to be issued.

[0061] The instruction identifier is a unique code used to identify an instruction, such as a globally unique identifier (UUID) generated by the service center or an incrementing numeric number, ensuring that each instruction can be accurately located in the offline instruction pool; the instruction content is data describing the specific operation command, such as the latitude and longitude coordinates of the navigation target point, the speed setpoint, or the mission abort flag, and is encapsulated in binary or text form; the instruction version number is a numerical value that identifies the iterative version of the instruction data. It is initially set to the first version and increments when the instruction changes due to modification, update, or regeneration, and is used to distinguish between the old and new versions of the instruction in differential calculations.

[0062] After the third instruction to be executed has completed instruction sequence number allocation, validity period calculation, and semantic conflict tag attachment, the six fields of instruction identifier, instruction content, instruction sequence number, instruction version number, validity period, and semantic conflict tag are serialized according to a preset structured format to form a complete instruction record. Specifically, first, a serialization format is selected according to the design requirements of the offline instruction pool. For example, when using JSON object format, an empty JSON object is created. Then, the instruction identifier is assigned as the string field name "cmdId", the instruction content is assigned as a binary string or Base64 encoded field "payload", the instruction sequence number is assigned as an integer type field "seq", the instruction version number is assigned as an integer type field "ver", the validity period is assigned as an ISO 8601 time string or Unix timestamp field "expireAt", and the semantic conflict tag is assigned as the string field "conflictTag" to the JSON object. After the assignment is completed, the JSON serialization library is called to convert the JSON object in memory into a UTF-8 encoded byte array or string, thus obtaining a complete JSON format instruction record. If Protocol Buffers format is used, a protobuf message structure is defined, which contains six corresponding fields (cmd_id is string, payload is bytes, seq is uint32, ver is uint32, expire_at is int64, and conflict_tag is string). Then, an instance of this message structure is created for each third instruction to be executed, the values ​​of each field are filled in, and finally the SerializeToString or SerializeToArray method of the protobuf library is called to serialize the message instance into a compact binary byte stream, resulting in a complete protobuf format instruction record. If a custom fixed-length / variable-length record format is used, the fixed offset and length of each field in the record are predefined (e.g., the instruction identifier is a 36-byte UUID string, the instruction sequence number is a 4-byte big-endian integer, the instruction version number is a 2-byte Unix timestamp, the validity period is an 8-byte Unix timestamp, the semantic conflict label is a 16-byte fixed-length string, and the instruction content is a variable-length field with a 2-byte length prefix appended to the header). Then, the values ​​of each field are written to a byte buffer in the specified byte order. For variable-length fields, the length is written first, followed by the content, and finally a complete custom-format instruction record is obtained.

[0063] Regardless of the format used, the instruction record obtained after serialization can be directly written as an independent entry into the ordered data structure of the offline instruction pool for subsequent differential calculation, binning and distribution steps. After that, the instruction record is inserted into the offline instruction pool with the instruction sequence number as the primary key or sorting key. The offline instruction pool usually adopts an ordered data structure (such as a balanced binary tree, skip list or relational database table) to ensure that all third instructions to be executed are stored in ascending order of instruction sequence number, thereby obtaining the set of instructions to be distributed. By unifying all the key attributes of each third instruction to be executed into a searchable, sortable and comparable structured record, the service center can directly and quickly locate inactive instructions based on the instruction sequence number, determine whether an update is needed based on the instruction version number, remove expired instructions based on the validity period, and perform mutual exclusion analysis based on semantic conflict tags when performing differential calculation, thus providing a complete and consistent data foundation for the operation of the entire instruction caching method.

[0064] In one feasible implementation, refer to Figure 3 As shown, step S20 may specifically include steps S21 to S23: Step S21: After obtaining the time point when the Beidou terminal completes the entry lock and the signal strength exceeds the preset signal strength, use the time point as the start time of the receivable window.

[0065] It should be noted that the Beidou terminal refers to the Beidou short message transceiver module installed on the unmanned vehicle, which is responsible for sending uplink data and receiving downlink data via Beidou satellites; entry lock refers to the Beidou terminal completing signal synchronization with Beidou satellites, identity authentication, and channel access preparation, and entering a working state where it can send uplink short messages normally; signal strength refers to the power level or signal-to-noise ratio of the satellite signal received by the Beidou terminal, used to measure the quality of the current communication link; preset signal strength is a pre-set signal quality threshold. If the signal strength is lower than this threshold, the communication error rate is too high, and data transmission should not be initiated; the receivable window refers to the available time period from when the Beidou terminal has stable transmission and reception capabilities until communication must be stopped due to power consumption control or frequency limitations.

[0066] The main control system of the unmanned vehicle sends a status query command to the Beidou terminal at a fixed period (e.g., once per second) via a serial port or internal bus. The Beidou terminal returns a status report containing the entry lock flag and the current signal strength value. The main control system continuously monitors the returned data. When it detects that the entry lock flag is true and the signal strength value exceeds the signal strength, it immediately reads the timestamp of the current system clock, uses this timestamp as the start time of the receivable window, and stores it in the unmanned vehicle's memory variable for use in subsequent steps.

[0067] The timing of the pull request is anchored to the first moment when the BeiDou terminal truly has stable communication capabilities. This avoids sending uplink messages blindly when the terminal has not completed the entry lock or the signal quality is insufficient, which could lead to transmission failure or data loss. Thus, under the constraints of limited BeiDou short message frequency and terminal power consumption sensitivity, it ensures that every uplink communication opportunity is effectively utilized, providing a reliable triggering point for subsequent command pull and distribution processes.

[0068] Step S22: Start the timer based on the start time.

[0069] After obtaining the start time of the receivable window, the main control system of the unmanned vehicle immediately calls the timer interface provided by the operating system or embedded firmware to create a single-trigger software timer and sets the timing start point of the software timer to the current time (i.e. the start time). At the same time, the timeout duration of the software timer is set to the pre-configured window duration (this duration is jointly determined by the power consumption management strategy of the Beidou terminal and the short message frequency limit).

[0070] Once the timer starts, it begins a countdown. During this period, the autonomous vehicle keeps its BeiDou terminal in a transmit / receive state. If the timer expires, the system triggers an interrupt or callback function, notifying the main control system that the receive window has ended. The system then shuts down the BeiDou terminal's receiving module or enters a low-power standby mode. The primary benefit of this approach is that it sets a clear and controllable duration boundary for the receive window, preventing the autonomous vehicle from indefinitely occupying the BeiDou terminal due to waiting for more instructions or repeated retries. This effectively manages the opening and closing of each communication window within the constraints of BeiDou short message frequency limits and the limited power of the autonomous vehicle. It ensures sufficient communication time for sending pull requests and receiving response packets while avoiding unnecessary power waste and frequency violations, providing a time guarantee for the reliable sending of pull requests and the stable reception of response packets in subsequent steps.

[0071] Step S23: During the operation of the timer, read the historical instruction sequence number of the historical executed instructions stored locally on the unmanned vehicle as the request effective sequence number, read the historical instruction version number received by the unmanned vehicle from the service center as the request version number, and obtain the upper limit value of the receiveable window as the receiving capacity budget, and then construct a pull request including the unmanned vehicle identifier, the request effective sequence number, the request version number and the receiving capacity budget.

[0072] It should be noted that "historical executed instructions" refers to instructions that the autonomous vehicle has successfully executed and confirmed to be effective in the past. The corresponding historical instruction sequence number is the request effective sequence number stored locally by the autonomous vehicle. This request effective sequence number records the highest instruction sequence number that the autonomous vehicle has executed. "Historical instruction version number" refers to the historical instruction version number carried by the autonomous vehicle when it last received a response packet from the service center. This historical instruction version number is updated by the service center every time an instruction is issued and is used to identify the current instruction set version status held by the autonomous vehicle. "Payment limit value" refers to the maximum number of data bytes that the autonomous vehicle's Beidou terminal can receive within the current receiveable window, based on its hardware capabilities and communication protocol. This payload limit value is usually obtained by subtracting the protocol overhead from the maximum effective payload length of a single Beidou short message packet.

[0073] During the operation period after the timer starts, the main control system of the unmanned vehicle first accesses the local persistent storage area (such as flash memory or file system) to read the historical instruction sequence number updated and saved after the last gating execution, and uses it as the request effective sequence number; then it reads the historical instruction version number extracted and saved from the service center response packet in the local storage, and uses it as the request version number; next, it reads the current receiveable window's payload limit value from the system configuration parameters. This payload limit value is determined by the Beidou terminal's model, working mode, and preset communication parameters, and serves as the receive capability budget; finally, the main control system encapsulates the four fields of unmanned vehicle identification (such as the Beidou terminal's device ID or the unmanned vehicle's unique number), request effective sequence number, request version number, and receive capability budget according to the Beidou short message uplink protocol format, for example, by writing them sequentially into a fixed-length byte array, and adding necessary frame headers and check fields, thereby constructing a complete pull request.

[0074] The pull request generated through the above steps carries the latest execution progress, version status, and receiving capability information of the unmanned vehicle. Upon receiving the request, the service center can accurately calculate the differential instruction set that the unmanned vehicle has not yet acquired and is currently valid without any additional historical records or interactions. The amount of data sent is strictly controlled within the range that the unmanned vehicle can receive in this window. Thus, the entire process from status reporting to accurate instruction matching is completed in a single uplink communication, which greatly improves the communication efficiency and the targeting of instruction issuance of Beidou short messages under frequency-limited conditions.

[0075] In one feasible implementation, refer to Figure 4 As shown, step S30 may specifically include steps S31 to S37: Step S31: Select the instruction to be issued from the set of instructions to be issued that has an instruction sequence number greater than the request effective sequence number and an instruction version number greater than the request version number as the first instruction to be issued.

[0076] It should be noted that the set of instructions to be issued is a collection of all instructions written into the offline instruction pool but not yet confirmed as effective or invalid. Each instruction to be issued carries its corresponding instruction sequence number and instruction version number. The requested effective sequence number is the highest instruction sequence number that the autonomous vehicle has executed, reported in the pull request. The requested version number is the instruction set version number that the autonomous vehicle currently holds, reported in the pull request. The first instruction to be issued refers to the instruction that meets the screening criteria and is initially considered to be likely to be issued.

[0077] Upon receiving a pull request, the service center first extracts the request's effective sequence number and request version number from the request. Then, since the instructions in the pending instruction set are stored in ascending order of instruction sequence number, the service center uses the request's effective sequence number as a benchmark to locate the first instruction in the pending instruction set whose sequence number is greater than the request's effective sequence number (a binary search algorithm can be used for quick location), and then traverses all instructions from that position. For each instruction encountered, its version number is compared with the request version number. If the instruction's version number is greater than the request version number, the instruction is added to the first pending instruction set; otherwise, the instruction is skipped.

[0078] After the traversal is completed, all instructions that simultaneously satisfy the condition that the instruction sequence number is greater than the requested effective sequence number and the instruction version number is greater than the requested version number constitute the first instruction to be issued. Through the dual filtering of instruction sequence number and instruction version number, instructions that have already been executed by the unmanned vehicle (instruction sequence number not greater than the requested effective sequence number) and instructions that the unmanned vehicle already holds or that are outdated (instruction version number not greater than the requested version number) are effectively excluded. Thus, only instructions that the unmanned vehicle truly lacks and that are updated in version are retained, thereby avoiding the waste of BeiDou short message resources due to duplicate issuance and version mismatch from the source.

[0079] Step S32: Based on the current time, select the first pending instructions that are within the validity period from the first pending instructions as the second pending instructions.

[0080] It should be noted that the current time refers to the system time when the service center performs the filtering operation.

[0081] After receiving multiple pending instructions, the service center first obtains the current system time as the current moment. Then, it iterates through each pending instruction, extracts its validity period, and compares the current moment with each validity period. If the current moment is less than or equal to a certain validity period, the corresponding pending instruction is considered still valid and retained, categorized as a second pending instruction. If the current moment is greater than a certain validity period, the corresponding pending instruction is considered expired and discarded. During the differential calculation process, all expired instructions are promptly eliminated, ensuring that all instructions participating in packing and issuance in subsequent steps are still valid and can be safely executed at the current moment. This fundamentally prevents the safety hazard of expired instructions being incorrectly issued to the autonomous vehicle and executed due to long queues in the cache queue or transmission delays, thus guaranteeing the timeliness of instruction issuance and the security of execution.

[0082] Step S33: Based on the semantic conflict tags of each second instruction to be issued, obtain the second instruction to be issued corresponding to the instruction sequence number in the first order from the second instructions to be issued belonging to the same mutually exclusive category, and obtain the candidate difference set.

[0083] It should be noted that the second pending instructions belonging to the same mutually exclusive category indicate that they operate on the same control dimension or operation object, and cannot take effect or be executed at the same time; because within the same mutually exclusive category, the second pending instruction with the largest instruction sequence number represents the latest operation intent of that category and should be reserved first.

[0084] The service center first iterates through all the second pending instructions, grouping those with the same semantically conflicting tags into the same temporary group. For each temporary group, the second pending instructions within that group are sorted from largest to smallest by instruction sequence number. The instruction with the largest sequence number is selected as the sole representative of the corresponding mutually exclusive category, and all other instructions are discarded. After performing the same operation on all mutually exclusive category groups, all the retained second pending instructions are gathered together to form a candidate difference set. This effectively eliminates semantic contradictions between multiple instructions within the same mutually exclusive category during the difference calculation process, retaining only the most recently generated instruction in each mutually exclusive category. This prevents the autonomous vehicle from simultaneously receiving multiple instructions belonging to the same control dimension but with conflicting content (e.g., receiving navigation instructions for two different target points simultaneously), fundamentally ensuring the semantic consistency of instruction issuance and avoiding chaotic task status or dangerous operations caused by instruction conflicts.

[0085] Step S34: Based on the instruction sequence number of each candidate instruction in the candidate difference set, sort the candidate instructions in ascending order of instruction sequence number to obtain the sorted candidate difference set.

[0086] Since the filtering and grouping operations in the aforementioned steps may have changed the original order of the instructions, it is necessary to reorder the candidate difference sets.

[0087] The service center first iterates through each candidate instruction in the candidate difference set and extracts its instruction sequence number as the sorting key. Then, it uses a stable sorting algorithm (such as quicksort or mergesort) to compare and rearrange all candidate instructions. The comparison rules are as follows: if the instruction sequence number of candidate instruction a is less than the instruction sequence number of candidate instruction b, then candidate instruction a is placed before candidate instruction b; if the instruction sequence number of candidate instruction a is greater than the instruction sequence number of candidate instruction b, then candidate instruction a is placed after candidate instruction b; if they are equal, they are retained in their original order.

[0088] During the sorting process, the instruction sequence number is used as the sole comparison criterion, without changing other attributes of the candidate instructions. After sorting, all candidate instructions are arranged in ascending order of instruction sequence number to obtain the sorted candidate difference set. This ensures that the instructions are strictly arranged in the order of generation during subsequent packing and distribution, enabling the unmanned vehicle to parse and execute them in the natural order of instruction sequence number after receiving them. This avoids the chaos in task status or logical errors caused by the unmanned vehicle executing instructions generated later due to disordered instruction order, and provides the correct input for sequentially accumulating the payload length and generating the index table in subsequent steps.

[0089] Step S35: Based on the sorted candidate difference set, the payload length of each candidate instruction is accumulated sequentially until the first accumulation result exceeds the receiving capability budget. The candidate instructions corresponding to the first accumulation result are then determined as the instruction set to be calculated.

[0090] It should be noted that payload length refers to the number of bytes occupied by the instruction content of each candidate instruction after being encoded by BeiDou short message.

[0091] The service center first initializes an accumulator counter, setting its value to zero. Then, following the sorted order of candidate instructions in the candidate difference set, it iterates sequentially starting from the first candidate instruction. For each candidate instruction encountered, its payload length is extracted, and the current accumulation result of the accumulator counter is added to the payload length of the current candidate instruction to obtain a new accumulation result. If the accumulation result is less than or equal to the receiver capability budget, the current candidate instruction is marked as a loadable instruction, and the accumulator counter is updated to the current accumulation result, continuing to traverse the next candidate instruction. If the accumulation result is greater than the receiver capability budget, the traversal stops immediately, and the current candidate instruction is not marked as a loadable instruction. All candidate instructions that have been marked as loadable instructions before this point constitute the instruction set to be calculated.

[0092] For example, assuming a receiver capacity budget of 70 bytes, and the payload lengths of the three candidate instructions in the sorted candidate difference set are 30 bytes, 25 bytes, and 20 bytes respectively, then they are added sequentially: 30 + 25 equals 55, which does not exceed the budget, so the first two are marked as loadable; continuing to add 55 + 20 equals 75, which exceeds the budget, so the traversal stops, the first two candidate instructions constitute the instruction set to be calculated, and the third candidate instruction is reserved for the next fetch request. In this way, within the upper limit of the single BeiDou short message transmission capacity, as many valid instructions as possible are loaded in ascending order of instruction sequence number, while strictly ensuring that the total amount of data loaded does not exceed the receiver capacity budget, thus avoiding data truncation or packet loss due to overload, and maximizing the utilization of bandwidth for each communication under the dual constraints of frequency and capacity.

[0093] Step S36: Based on the payload content corresponding to each instruction in the instruction set to be calculated, determine the starting offset position of each instruction to be calculated and the instruction length of each instruction to be calculated, and then supplement each starting offset position and each instruction length into the sorted candidate difference set to obtain the index table.

[0094] It should be noted that the starting offset position refers to the starting byte position of the payload content of each instruction to be calculated in the final differential payload data block; the instruction length refers to the number of bytes occupied by the payload content of each instruction to be calculated.

[0095] First, the payload content of each instruction in the instruction set to be calculated is obtained, and its byte length is measured as the instruction length of that instruction. Then, a current offset variable is initialized and its value is set to zero. Next, according to the order of the instruction set in the sorted candidate difference set (i.e., the order of instruction sequence numbers from smallest to largest), a starting offset position is assigned to each instruction to be calculated in turn: the current value of the current offset variable is used as the starting offset position of the corresponding instruction to be calculated, and then the current offset variable is increased by the instruction length of that instruction to obtain the updated current offset variable, which is used to calculate the starting offset position of the next instruction to be calculated. After traversing all the instructions to be calculated, each instruction to be calculated obtains a unique starting offset position and a corresponding instruction length. Finally, these starting offset positions and instruction lengths are added as new fields and appended to each instruction to be calculated in the sorted candidate difference set, thus forming an index table that includes instruction sequence number, starting offset position, and instruction length. This establishes a byte-level position mapping for each instruction to be calculated in the differential payload, enabling the autonomous vehicle to accurately cut out the payload content of each instruction from the payload data block based on the starting offset position and instruction length recorded in the index table after receiving the differential payload, without additional protocol interaction or guesswork. This ensures the correctness and efficiency of the parsing and provides reliable data input for subsequent execution gating.

[0096] Step S37: Fill the load content of each instruction to be calculated into the index table to obtain the differential load.

[0097] It should be noted that the differential load refers to the final complete data block that includes the index table and the contents of each instruction load to be calculated.

[0098] The service center creates an empty data buffer, the size of which is equal to the last starting offset position calculated in the previous step plus the instruction length of the last instruction to be calculated. Then, the index table is written into the starting position of the data buffer according to a preset format (e.g., a fixed-length record sequence arranged in ascending order of instruction sequence number), that is, the entire contents of the index table are written starting from the first byte of the data buffer, and the length of bytes occupied by the index table is recorded. Next, according to the order of the instructions to be calculated in the sorted candidate difference set, each instruction to be calculated is traversed in turn. For the instruction to be calculated that is currently traversed, its payload content is extracted, and according to the starting offset position determined by the instruction to be calculated, the payload content is written into a continuous byte area in the data buffer starting from the starting offset position, and the writing length is equal to the instruction length of the corresponding instruction to be calculated.

[0099] After all the payload contents of the instructions to be calculated have been written according to their respective starting offset positions, the area in the data buffer from the end of the index table to the end of the data buffer is the result of tightly splicing the payload contents of each instruction to be calculated according to their offset positions. At this time, the data in the entire data buffer constitutes the differential payload, with the index table located at the beginning and the payload contents of each instruction to be calculated arranged sequentially after it according to their starting offset positions.

[0100] In this step, by organically integrating the index table with the payload content of each instruction to be calculated into a self-describing differential payload that can be directly sent in a single BeiDou short message, the unmanned vehicle can obtain the storage location of each instruction to be calculated in the payload data area by parsing the index table in the header after receiving the differential payload. This allows for the accurate cutting and restoration of the complete content of each instruction to be calculated without additional protocol interaction or data reassembly, ensuring efficient transmission and reliable parsing of the differential payload under the capacity constraints of BeiDou short messages.

[0101] In one feasible implementation, refer to Figure 5 As shown, step S40 may specifically include steps S41 to S43: Step S41: Calculate the lightweight check value based on the payload byte of the differential payload, the request effective sequence number in the pull request, and the request version number.

[0102] The payload byte of the differential payload refers to the binary content of the differential payload generated in step S37; the lightweight check value is a fixed-length check code used to verify whether the response packet has been corrupted or tampered with during the BeiDou short message transmission process.

[0103] The service center first converts the request effective sequence number into a four-byte big-endian representation, and also converts the request version number into a four-byte big-endian representation. Then, it concatenates the payload bytes of the differential payload, the four-byte big-endian representation of the request effective sequence number, and the four-byte big-endian representation of the request version number into a continuous input byte sequence in sequence.

[0104] Next, using the input byte sequence as the data to be checked, the standard implementation of the CRC32 algorithm is called. This algorithm uses the generator polynomial 0x04C11DB7, sets the initial check value to 0xFFFFFFFF, and performs polynomial division on the input byte sequence byte by byte or bit by bit. After processing each input byte, the check value is updated. After all bytes have been processed, the final check value is XORed with 0xFFFFFFFF to obtain a 32-bit unsigned integer, which is the CRC32 check value and is used as a lightweight check value.

[0105] This lightweight checksum is subsequently appended to the response packet, allowing the autonomous vehicle to perform the same calculation upon receipt and compare it with the received lightweight checksum to determine data integrity. In this step, a lightweight checksum is generated by binding the payload bytes of the differential payload with the request version number (the sequence number of the request in the pull request). This enables the autonomous vehicle to independently verify whether bit errors or tampering occurred in the differential payload during BeiDou short message transmission by recalculating and comparing the lightweight checksum after receiving the response packet. Thus, without the constraint of native end-to-end acknowledgment in BeiDou short messages, this provides a lightweight and effective layer of data integrity assurance for the autonomous vehicle, avoiding the security risk of executing incorrect instructions due to data corruption.

[0106] Step S42: Generate the header fields of the response packet based on the request effective sequence number and the request version number.

[0107] Extract the request effective sequence number from the pull request and set it directly as the base sequence number in the response packet header field. This base sequence number is used to inform the autonomous vehicle of the starting sequence number position corresponding to this differential payload, so that the autonomous vehicle can align the received instructions to be calculated with its own execution progress. Then, obtain the latest instruction version number of the current offline instruction pool and set this latest instruction version number as the new version number in the response packet header field. This new version number is usually greater than or equal to the request version number and is used to inform the autonomous vehicle which version of the instruction has been updated to after this response packet is issued.

[0108] Finally, the baseline sequence number and the new version number are written into a fixed position in the header field according to the preset field order and byte length (e.g., the baseline sequence number occupies four bytes and the new version number occupies two bytes) to form the header field of the response packet. This provides the autonomous vehicle with the context information corresponding to this response packet, enabling the autonomous vehicle to align the received instructions to be calculated with its own request effective sequence number when parsing differential payloads in the future, and update the local instruction version number. This ensures that the execution status of maintenance on the autonomous vehicle side is consistent with that of the service center, laying the foundation for reporting the correct request effective sequence number and request version number in the next pull request.

[0109] Step S43: The differential payload, lightweight check value, and header fields are spliced ​​together according to the frame format of BeiDou short messages to obtain the response packet.

[0110] According to the frame format specification of the BeiDou short message downlink, an empty data frame buffer is created. The length of the data frame buffer is equal to the sum of the byte lengths of the header field, differential payload, and lightweight check value. Then, according to the preset frame structure order, the header field is first written to the beginning position of the data frame buffer, followed by the complete byte sequence of the differential payload written to the position after the header field, and finally the lightweight check value written to the position after the differential payload, thus forming a continuous byte sequence, i.e., the response packet.

[0111] This byte sequence constitutes a complete BeiDou short message data frame. The header field at the beginning of the frame provides context identification, the differential payload carries command data in the middle, and the lightweight checksum at the end is used for integrity verification. After concatenation, this BeiDou short message data frame can be directly submitted to the BeiDou short message sending device for downlink transmission.

[0112] In this step, by organizing the header field, differential payload, and lightweight check value into a response packet according to the frame structure specified in the BeiDou short message protocol, the BeiDou terminal of the unmanned vehicle can parse the header field, differential payload, and lightweight check value in the same order after receiving the response packet. This enables context alignment, instruction data extraction, and integrity verification, without requiring additional protocol negotiation or segmented transmission between the service center and the unmanned vehicle. Under the condition of limited single packet capacity of BeiDou short message, standardized encapsulation and reliable transmission of the response packet are achieved.

[0113] In one feasible implementation, refer to Figure 6 As shown, step S50 may specifically include steps S51 to S53: Step S51: Perform integrity verification on the header field and differential payload based on the lightweight check value to obtain the verified header field and the verified differential payload.

[0114] After receiving the response packet, the autonomous vehicle first extracts the header field, differential payload, and lightweight checksum from the packet. Then, it converts the baseline sequence number and new version number in the header field into four-byte big-endian representations, and concatenates the sum of the differential payload bytes with these two four-byte big-endian representations in sequence to form a continuous byte sequence. Next, it uses the same Cyclic Redundancy Check (CRC32) algorithm as the service center (using the generator polynomial 0x04C11DB7, setting the initial checksum to 0xFFFFFFFF, processing the input data byte by byte, and finally XORing and inverting it with 0xFFFFFFFF) to calculate a 32-bit local checksum.

[0115] Finally, the local checksum is compared with the lightweight checksum extracted from the response packet. If the two are completely consistent, it is determined that no bit errors or tampering have occurred in the header field and differential payload during transmission, and the header field and differential payload are marked as verified, thus obtaining the verified header field and the verified differential payload. If the two are inconsistent, it is determined that the data has been corrupted, and the response packet is discarded or a retransmission mechanism is triggered.

[0116] By comparing lightweight check values, the unmanned vehicle can independently verify whether the header field and differential payload in the response packet have maintained integrity during the BeiDou short message transmission process. Thus, under the condition of BeiDou short message transmission without native end-to-end confirmation, it provides reliable data protection for subsequent command segmentation and execution, preventing the unmanned vehicle from parsing incorrect commands or performing dangerous operations due to data corruption.

[0117] Step S52: Based on the starting offset position and instruction length of each instruction to be calculated in the response packet, the differential load after verification is cut to obtain the load content of each instruction to be calculated.

[0118] The autonomous vehicle parses an index table from the response packet. The index table records the starting offset and instruction length of each instruction to be calculated in ascending order of instruction sequence number. Then, the autonomous vehicle traverses each instruction to be calculated in the index table, using the starting offset of the currently recorded instruction as the starting point and the instruction length of the currently recorded instruction as the reading length. It locates the corresponding position of the load content of each instruction to be calculated in the original differential load in the verified differential load, and continuously reads a specified length of byte data from that position to obtain the load content of the currently recorded instruction to be calculated. This operation is repeated until all instructions to be calculated in the index table have been processed, thereby obtaining the load content of each instruction to be calculated.

[0119] By utilizing the byte-level position mapping pre-established in the index table, the payload content of each instruction to be calculated is extracted from the continuous differential payload without additional protocol interaction or data reassembly, ensuring the correctness and efficiency of the parsing process, and providing accurate and independent payload content for subsequent instruction sequence number completion and execution gating.

[0120] Step S53: Based on the instruction sequence number of each instruction to be calculated and the verified header field, complete the payload content to obtain the complete instruction sequence number, and combine the complete instruction sequence number with the instruction identifier and instruction content in the payload content to obtain instruction entries arranged according to the complete instruction sequence number.

[0121] The autonomous vehicle first extracts the baseline sequence number from the verified header field, then it traverses each record in the index table. For the current record, it reads the instruction sequence number stored in the record. This instruction sequence number is stored in the differential payload in the form of an offset relative to the baseline sequence number to save byte space. The autonomous vehicle adds this offset to the baseline sequence number to obtain the complete instruction sequence number of the corresponding instruction to be calculated.

[0122] Next, after parsing the instruction identifier and instruction content from the payload content corresponding to the instruction to be calculated obtained in the previous step, the complete instruction sequence number, instruction identifier and instruction content are combined into a structured instruction entry, and arranged in ascending order of the complete instruction sequence number to obtain the instruction entry arranged by the complete instruction sequence number.

[0123] In this step, by adding the instruction sequence number in the index table to the base sequence number in the header field, a globally unique and monotonically increasing complete instruction sequence number for each instruction to be calculated is restored. This enables the autonomous vehicle to accurately identify the generation order and unique identity of each instruction to be calculated. Consequently, in subsequent execution gating, the execution progress can be judged based on the instruction sequence number, duplicate execution can be avoided, and the execution order of the instructions can be strictly consistent with the order generated by the service center.

[0124] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for offline command caching of unmanned vehicles based on BeiDou short message service, characterized in that, include: The instructions to be executed that arrive at the unmanned vehicle are written into the offline instruction pool of the unmanned vehicle in the form of preset instructions to obtain a set of instructions to be issued. Within the receptive window of the detected BeiDou terminal, a pull request is constructed based on the historical data of the unmanned vehicle. The pull request includes the unmanned vehicle identifier, the request effective sequence number, the request version number, and the receiving capability budget. Based on the BeiDou short message uplink, after the pull request is sent to the service center, the service center performs differential calculation on the set of instructions to be issued according to the effective sequence number of the request and the version number of the request, and after obtaining the candidate differential set, the differential payload is calculated according to the candidate differential set. The candidate difference sets are sorted in ascending order according to the preset instruction sequence number and packed under the constraint of the receiving capability budget to obtain the response packet. The response packet is then sent to the unmanned vehicle through the Beidou short message downlink. The differential payload is parsed based on the response packet to obtain instruction entries. Then, execution gating is performed based on the instruction entries to obtain the execution result sequence, the locally updated effective sequence number, and the set of unexecuted instructions. The offline instruction pool is trimmed according to the locally updated effective sequence number, and the instructions in the offline instruction pool are invalidated according to the unexecuted instruction set to obtain the updated offline instruction pool.

2. The offline command caching method for unmanned vehicles based on BeiDou short messages according to claim 1, characterized in that, The step of writing the pending instructions arriving at the unmanned vehicle into the unmanned vehicle's offline instruction pool in a preset instruction format to obtain a set of instructions to be issued includes: Based on the arrival order of each instruction to be executed, assign each instruction to be executed an instruction sequence number that monotonically increases according to the arrival order to obtain the first instruction to be executed; Based on the generation time of the first instruction to be executed and the preset validity period, the validity period of the first instruction to be executed is calculated to obtain the second instruction to be executed; Generate a semantic conflict tag corresponding to the second instruction to be executed, and assign it to the corresponding second instruction to be executed to obtain the third instruction to be executed; After converting the instruction identifier, instruction content, instruction sequence number, instruction version number, validity period, and semantic conflict tag of each of the third instructions to be executed into structured fields, they are written into the offline instruction pool to obtain the set of instructions to be issued.

3. The offline command caching method for unmanned vehicles based on BeiDou short messages according to claim 1, characterized in that, The step of constructing a pull request based on the historical data of the unmanned vehicle within the detected receive window of the Beidou terminal includes: After obtaining the time point when the Beidou terminal completes the entry lock and the signal strength exceeds the preset signal strength, the time point is used as the start time of the receivable window; Start the timer based on the stated start time; During the operation of the timer, the historical instruction sequence number of the historical executed instructions stored locally on the unmanned vehicle is read as the request effective sequence number, the historical instruction version number received by the unmanned vehicle from the service center is read as the request version number, and the load limit value of the receiveable window is obtained as the receiving capacity budget. Then, the pull request is constructed, which includes the unmanned vehicle identifier, the request effective sequence number, the request version number and the receiving capacity budget.

4. The offline command caching method for unmanned vehicles based on BeiDou short messages according to claim 1, characterized in that, The step of performing difference calculation on the set of instructions to be issued based on the effective sequence number of the request and the version number of the request at the service center to obtain a candidate difference set includes: Select the instruction to be issued from the set of instructions to be issued, and select the instruction to be issued whose instruction sequence number is greater than the effective sequence number of the request and whose instruction version number is greater than the version number of the request as the first instruction to be issued; Based on the current time, select the first pending instructions that are within the validity period from each of the first pending instructions as the second pending instructions; Based on the semantic conflict tags of each of the second instructions to be issued, the second instruction to be issued corresponding to the instruction sequence number in the first order is obtained from the second instructions to be issued belonging to the same mutually exclusive category, and the candidate difference set is obtained.

5. The offline command caching method for unmanned vehicles based on BeiDou short messages according to claim 4, characterized in that, The step of calculating the differential load based on the candidate difference set includes: Based on the instruction sequence number of each candidate instruction in the candidate difference set, the candidate instructions are sorted in ascending order of the instruction sequence number to obtain the sorted candidate difference set; Based on the sorted candidate difference set, the payload length of each candidate instruction is sequentially accumulated until the first accumulation result exceeds the receiving capability budget. The candidate instructions corresponding to the first accumulation result are then determined as the instruction set to be calculated. Based on the payload content corresponding to each instruction in the instruction set to be calculated, the starting offset position of each instruction to be calculated and the instruction length of each instruction to be calculated are determined. Then, the starting offset position and the instruction length are added to the sorted candidate difference set to obtain an index table. The load content of each instruction to be calculated is filled into the index table to obtain the differential load.

6. The offline command caching method for unmanned vehicles based on BeiDou short messages according to claim 1, characterized in that, The step of packing the packets under the constraint of the receiving capacity budget to obtain the response packets includes: The lightweight check value is calculated based on the payload bytes of the differential payload, the request effective sequence number in the pull request, and the request version number. Generate the header fields of the response packet based on the request effective sequence number and the request version number; The differential payload, the lightweight check value, and the header fields are concatenated according to the frame format of the BeiDou short message to obtain the response packet.

7. The offline command caching method for unmanned vehicles based on BeiDou short messages according to claim 6, characterized in that, The step of parsing the differential payload based on the response packet to obtain the instruction entries includes: Based on the lightweight check value, integrity checks are performed on the header field and the differential payload to obtain the checked header field and the checked differential payload. Based on the starting offset position and instruction length of each instruction to be calculated in the response packet, the verified differential load is cut to obtain the load content of each instruction to be calculated. Based on the instruction sequence number of each instruction to be calculated and the verified header field, complete the payload content to obtain a complete instruction sequence number, and combine the complete instruction sequence number with the instruction identifier and instruction content in the payload content to obtain instruction entries arranged according to the complete instruction sequence number.

Images