Spaceborne software adaptive distribution and control method for can bus

Abstract

This application relates to a spaceborne software adaptive distribution and control method for CAN bus. This method achieves hardware-level switching between point-to-point and broadcast distribution by re-encoding the bit fields of extended identifiers. The software upgrade file is divided into data blocks and base frames at a two-level granularity and sent concurrently using a sliding window mechanism. The receiver returns acknowledgment frames carrying bit mapping information at the data block level to support accurate retransmission. The sender dynamically adjusts the window size and inter-frame interval based on the return delay and packet loss rate of the acknowledgment frames, and resumes distribution from the interrupted data block based on the offset information fixed by the receiver after a distribution interruption. This application has the advantages of high distribution efficiency, accurate retransmission, adaptive rate, and interrupt recovery.

Description

Technical Field

[0001] This application relates to the field of satellites, and in particular to an adaptive distribution and control method for onboard software oriented towards a CAN bus. Background Technology

[0002] During on-orbit operation, onboard computers and various payload units require software updates via on-orbit injection to enable functional expansion, fault repair, and mission reconfiguration. The CAN bus, due to its flexible topology, good fault tolerance, and low protocol overhead, has become the backbone bus in the internal communication of most satellite platforms, typically operating at a baud rate of 500kbps or 1Mbps, with a single frame data payload of only 8 bytes. When the injected object is a software upgrade file of several megabytes, the distribution process takes a considerable amount of time due to limitations in bus bandwidth and single-frame payload, placing demands on the efficiency and reliability of the distribution protocol far exceeding those of conventional telemetry and remote control scenarios.

[0003] In this scenario, the onboard CAN bus software distribution faces a set of deep-seated contradictions. The distribution process involves hundreds of thousands of fine-grained basic frames. On long-latency links, the stop-and-wait protocol, which waits for an acknowledgment after each frame is sent, will cause the actual bus throughput to be lower than the theoretical limit for a long time, and the time taken for a single complete distribution is unacceptable. If it is changed to blind high-speed continuous transmission without feedback, the receiver is prone to buffer overflow under the premise of limited fixed speed, which will lead to a chain of frame drops. If the traditional global retransmission mechanism is used after frame drops, short-term link deterioration caused by high-energy particle events in space or attitude maneuvers will cause a large number of correctly received frames to be repeatedly retransmitted, further squeezing the already tight bandwidth. If accurate retransmission is to be achieved, it is necessary to deal with the sharp conflict between feedback information and the 8-byte payload of a single CAN frame: directly carrying the receive status bitmap of each data block exceeds the capacity limit of a single acknowledgment frame.

[0004] A deeper problem lies in the fact that even if these conflicts are mitigated one by one, the limitations of the non-volatile memory write speed and lifespan of the onboard receiver, as well as the possibility of restarts, interruptions, or denial-of-service events during the upgrade process, still necessitate that the distribution scheme simultaneously considers runtime throughput, abnormal state recovery, and state continuity across mission cycles. Most existing onboard software uploading schemes focus on a single aspect of these aspects, lacking a holistic control framework that integrates addressing, fragmentation, concurrent transmission, adaptive rate adjustment, hardening protection, and breakpoint recovery into a coordinated closed loop. Under the combined effects of bandwidth constraints and the space environment, it is difficult to simultaneously achieve distribution efficiency, reliability, and endurance. Summary of the Invention

[0005] To achieve efficient distribution, accurate retransmission, adaptive rate adjustment, and interrupt recovery under the bandwidth and load constraints of the spaceborne CAN bus, this application provides a spaceborne software adaptive distribution and control method for the CAN bus.

[0006] This application provides a spaceborne software adaptive distribution and control method for CAN bus, which adopts the following technical solution: An onboard software adaptive distribution and control method for CAN bus, executed collaboratively by the sender and receiver, includes the following steps: S1. The extended identifier of the CAN bus is re-encoded into source address field, destination address field, frame type field and sequence number field by bit, and the hardware filtering based on the extended identifier switches between point-to-point mode and broadcast distribution mode according to the value of the destination address field. S2. Divide the software upgrade file to be distributed into multiple data blocks, and further divide each data block into multiple base frames to obtain the frame sequence of the data blocks, wherein each base frame carries a CAN extended identifier message; S3. The frame sequence is sent in advance using the sliding window mechanism with the basic frame as the unit. After the sender continuously sends the number of basic frames corresponding to the window size of the sliding window, it does not wait for frame-by-frame acknowledgment. After the receiver receives a data block, it returns an acknowledgment frame. The acknowledgment frame carries bit mapping information that represents the reception status of each basic frame in the data block. S4. Based on the return delay of the response frame and the packet loss rate reflected by the bit mapping information, dynamically adjust the window size of the sliding window and the inter-frame interval between two adjacent base frames of the sender. S5. In response to a distribution interruption, obtain the offset information of the data blocks that have been fully received and stored from the receiver, and reinitialize the sliding window from the next data block corresponding to the offset information to resume distribution.

[0007] By adopting the above technical solution, the protocol layer addressing of extended identifiers, the two-layer fragmentation of data blocks and base frames, the sliding window transmission with base frames as the advancing unit, the bit mapping feedback with data blocks as the granularity, and the breakpoint resumption organization based on fixed offsets are integrated into a collaborative closed loop. This enables the sender to break through the throughput limit of the stop-and-wait protocol on long-latency links, and the receiver to send back accurate base frame-level reception status to the sender in units of data blocks under the CAN single-frame 8-byte payload limit. Based on this, the sender only performs retransmission for missing base frames. At the same time, it dynamically adjusts the window size and inter-frame interval according to the response frame return delay and packet loss rate to adapt to the real-time status of the link. After the distribution process is interrupted due to spatial environmental disturbances or platform events, it can also directly recover from the broken data blocks, avoiding the retransmission of fixed data blocks.

[0008] Optionally, the bit mapping information in S3 adopts a two-level bitmap encoding: the first-level segment bitmap divides the data block into several segments, and the reception status of each segment is represented by a corresponding bit in the first-level segment bitmap; the second-level frame bitmap expands only the segments represented in the first-level segment bitmap as having an unreceived basic frame, and each bit in the second-level frame bitmap corresponds to the reception status of a basic frame in the corresponding segment; the number of segments ensures that the reception status bits of the basic frames contained in each segment can be accommodated by the remaining bytes in the acknowledgment frame excluding the bytes carrying the first-level segment bitmap.

[0009] By adopting the above technical solution, in the common case where all segments of the data block are received completely, only a single acknowledgment frame is needed to complete the confirmation. Only when some segments have lost frames is a fine-grained description added with a second-level frame bitmap, and the feedback overhead adaptively shrinks with the actual packet loss distribution.

[0010] Optionally, S4 includes the following sub-steps: S41. Obtain the packet loss rate by statistically analyzing the bit mapping information, and compare the packet loss rate with preset acceleration thresholds and deceleration thresholds, where the acceleration threshold is less than the deceleration threshold; S42. In response to the packet loss rate exceeding the deceleration threshold, reduce the window size of the sliding window by a preset ratio, and simultaneously increase the inter-frame interval by a preset increment; S43. In response to the packet loss rate being lower than the acceleration threshold and lasting for a preset number of response cycles, increase the window size of the sliding window by a preset increment, while keeping the inter-frame interval unchanged; S44. In response to the packet loss rate being between the acceleration threshold and the deceleration threshold, the window size of the sliding window and the inter-frame interval remain unchanged.

[0011] By adopting the above technical solution, the hysteresis band is formed by the dual thresholds of acceleration and deceleration, so that the window parameters remain stable when the link status jitters near the threshold. At the same time, the linkage adjustment of window size and inter-frame interval realizes dual-dimensional control of concurrency and instantaneous transmission rate, and the deceleration response is faster than single-dimensional adjustment.

[0012] Optionally, in S3, the response frame returned by the receiver also carries a water level field representing the remaining capacity of the receive buffer; S4 further includes: dynamically adjusting the speed-up threshold and the speed-down threshold according to the water level field, in response to the remaining capacity indicated by the water level field being lower than a preset low water level threshold, lowering the speed-up threshold; in response to the remaining capacity indicated by the water level field being higher than a preset high water level threshold, both the speed-up threshold and the speed-down threshold are raised.

[0013] By adopting the above technical solution, the sender can adjust the acceleration / deceleration criteria based on the tension of the receiver's buffer in the feedforward stage before packet loss occurs, avoiding the adjustment lag caused by relying solely on post-packet loss feedback.

[0014] Optionally, S5 includes the following sub-steps: S51. In response to the recovery request after the distribution interruption, send an offset query request to the receiver; S52. Receive the offset information returned by the receiver, the offset information indicating the cumulative byte position of the last data block that the receiver has fully received and fixed in the software upgrade file; S53. Determine the recovery starting data block based on the offset information, and reinitialize the sliding window and resume the transmission of the frame sequence starting from the recovery starting data block.

[0015] By adopting the above technical solution, the starting point of recovery after interruption is strictly anchored to the actual byte position of the receiver, the solidified data block is no longer sent repeatedly, and the status query of the recovery path and the initialization of the sliding window are connected as a complete handshake.

[0016] Optionally, the offset information includes a first offset and a second offset: the first offset is maintained by the receiver in random access memory and updated each time the receiver completely receives a data block; the second offset is maintained by the receiver in several cyclically written log slots in non-volatile memory, and written to the next log slot with an incrementing version number each time the receiver completely receives a predetermined number of data blocks; in S53, the sender responds to the first offset being valid and not less than the second offset by using the next data block corresponding to the first offset as the recovery starting data block; responds to the first offset being invalid or less than the second offset by reading the second offset recorded in the slot with the largest version number and which has passed verification from the several log slots, and uses the next data block corresponding to the second offset as the recovery starting data block.

[0017] By adopting the above technical solution, the non-volatile memory only undergoes a solid-state write once when crossing several data blocks, which significantly extends the erase and write life of the storage medium; at the same time, the coordinated comparison of the first offset and the second offset ensures that even if the receiver restarts and the random access memory is lost, the recovery can still use the latest version verified in the circular log as the lower bound.

[0018] Optionally, in S3, the response frame returned by the receiver also carries a solidification status flag. The solidification status flag is used to indicate whether the receiver is in the solidification window period for writing data blocks from random access memory to non-volatile memory. During the execution of S3, in response to the receiver completely receiving a certain data block and the solidification status flag indicating that the receiver is in the solidification window period for solidifying the data block, the sender does not stop sending the frame sequence, but switches to prefetch mode and sends a metadata frame of the data block after a certain data block to the receiver during the solidification window period. The metadata frame carries the sequence number of the data block after a certain data block, the number of basic frames contained therein, and the corresponding offset, so that the receiver can initialize the receiving context of the data block after a certain data block based on the metadata frame after solidification.

[0019] By adopting the above technical solution, the receiver's solidification window period is transformed from a transmission idle period into a metadata prefetching period. The receiver can enter the receiving preparation state for the next data block based on the received metadata frame the moment solidification is completed, thus eliminating the connection gap introduced by the solidification operation.

[0020] Optionally, in S2, the end of the frame sequence of each data block contains an end frame. The end frame carries a triple, which includes the starting sequence number of the next data block, the number of basic frames contained in the next data block, and the offset accumulated to the current data block. During the execution of S3, the receiver receives any end frame in response to its own restart event, initializes the receiving context of the next data block based on the triple carried by the end frame, and restores the receiving frame sequence.

[0021] By adopting the above technical solution, each end frame simultaneously serves as the completion marker of the previous data block and the receiving anchor point of the next data block. Even if the receiver restarts at any time, it can reconstruct the complete receiving context by relying solely on the next arriving end frame, saving the round-trip time of re-handshaking with the sender.

[0022] Optionally, in S4, the window size of the sliding window is adjusted in conjunction with the number of basic frames contained in the data block. In response to the packet loss rate exceeding the deceleration threshold, the window size of the sliding window is reduced while the number of basic frames contained in the data block is reduced. In response to the packet loss rate being lower than the acceleration threshold and lasting for a preset number of response cycles, the window size of the sliding window is increased while the number of basic frames contained in the data block is increased.

[0023] By adopting the above technical solutions, the data block fragmentation granularity is reduced synchronously when the link deteriorates, fewer base frames are covered in a single response feedback, and the timeliness of feedback between the first-level segment bitmap and the second-level frame bitmap is further improved.

[0024] Optionally, the bit mapping information carried in the response frame in S3 is organized using run-length encoding, and the reception status is represented by a sequence that alternates between the number of consecutively received base frames and the number of consecutively unreceived base frames.

[0025] By adopting the above technical solution, the response frame payload is adaptively compressed according to the concentrated distribution of the receiving state in the typical burst packet loss scenario of the space channel, serving as a supplementary adaptation form to the segment bitmap coding method.

[0026] Optionally, during periods of link stability, periodic acknowledgments can be cancelled. When the receiver detects a jump in the sequence number of the base frame, it can proactively send a denial frame. The denial frame carries the base frame interval corresponding to the jumped sequence number to request retransmission.

[0027] By adopting the above technical solution, the feedback overhead under a stable link is linearly related to the actual packet loss rate rather than to the number of data blocks, thereby further reducing the bus bandwidth occupied by the feedback signaling.

[0028] Optionally, S4 further includes: recording the response frame return delay sequence of multiple consecutive data blocks, and in response to the continuous upward trend of the response frame return delay sequence, slightly reducing the window size of the sliding window in advance before packet loss occurs.

[0029] By adopting the above technical solution, congestion control is shifted from post-event triggering based on packet loss to pre-event triggering based on delay gradient, thereby improving the sensitivity of rate adjustment to link degradation.

[0030] Optionally, when in broadcast distribution mode in S1, feedback time slots based on destination addresses are allocated to several receivers. Each receiver returns a denial frame only within its own feedback time slot. The sender takes the union of the denial frames from several receivers and performs broadcast retransmission on the base frame marked as unreceived by any receiver.

[0031] By adopting the above technical solution, the feedback from multiple receivers in the broadcast distribution mode is staggered in the time domain to avoid bus arbitration conflicts, and the basic frames that have been received by several receivers are no longer retransmitted to avoid bandwidth waste.

[0032] Optionally, several bits of the frame type field in S1 are used to distinguish between handshake, data, response and end categories, while the remaining bits are used to carry metadata about whether this frame is the first or last frame of a data block and whether this data block is the final data block of a software upgrade file.

[0033] By adopting the above technical solution, the receiver can identify the data block boundary and the software upgrade file boundary without waiting for the end frame, and can perform cache allocation and tail data block processing in advance.

[0034] Optionally, the receiver uses the remainder obtained by taking the modulo of the sliding window size with the base frame sequence number as the bitmap index to maintain the base frame reception state. The size of the bitmap is adjusted with the sliding window size but does not change with the data block size.

[0035] By adopting the above technical solution, the memory occupied by the receiver's base frame reception status bitmap is fixed within a small range, avoiding the need to reserve large blocks of continuous memory space for large data blocks.

[0036] Optionally, S4 further includes: maintaining the base frame check failure distribution characteristics reflected by the response frame; in response to an increase in the proportion of burst check failures in the distribution characteristics, selecting to organize the bit mapping information in run-length encoding and using a more conservative sliding window size; and in response to an increase in the proportion of random check failures in the distribution characteristics, selecting to organize the bit mapping information in two-level bitmap encoding and using a more aggressive sliding window size.

[0037] By adopting the above technical solutions, the response frame coding method and sliding window strategy can be differentiated according to the real-time distribution of channel error types, realizing the upgrade from rate regulation to channel awareness.

[0038] In summary, this application includes at least one of the following beneficial technical effects: 1. By re-encoding the extended identifier bit field, the two-layer fragmentation of data blocks and base frames, and the bit mapping feedback at the data block granularity, the sender can still obtain accurate reception status feedback down to the base frame level under the hard constraint of 8-byte payload per CAN frame, and accordingly only retransmit missing base frames, thus improving data throughput and retransmission accuracy simultaneously.

[0039] 2. By adjusting the sliding window size and inter-frame interval in a two-dimensional linkage, using dual threshold hysteresis bands for acceleration and deceleration, and feedforward feedback of receiver buffer level, the rate adjustment can respond quickly when the link deteriorates, increase gently when the link is stable, and remain stable near the threshold, thus avoiding lag in single-dimensional adjustment and oscillations near the threshold.

[0040] 3. By using a two-layer hierarchical solidification of the first offset and the second offset, the end frame triplet to preview the receiving context of the next data block, and the metadata prefetching during the solidification window, the distribution process can simultaneously take into account three dimensions: non-volatile memory write lifetime protection, rapid context reconstruction after receiver restart, and pipelined connection between solidification operation and transmission operation. Attached Figure Description

[0041] Figure 1 A flowchart illustrating an embodiment of the onboard software adaptive distribution and control method for CAN bus is shown. Detailed Implementation

[0042] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0043] This application provides a spaceborne software adaptive distribution and control method for CAN bus, referring to... Figure 1This method, comprising S1-S5, organizes the software upgrade file distribution process into a closed loop executed collaboratively by the sender and receiver, within the constraints of the onboard CAN bus bandwidth and single-frame payload. The sender is the onboard master control computer, and the receiver is the payload computer or other onboard embedded computing units. The method achieves protocol layer addressing by re-encoding the bit segments of the CAN extended identifier, achieves efficient concurrent transmission through two-layer granular division of the upgrade file and sliding window transmission, achieves accurate retransmission through bit mapping feedback at the data block level, achieves rate adaptation through the linkage adjustment of window size and inter-frame interval, and achieves accurate recovery after interruption through breakpoint resumption based on fixed offsets.

[0044] In this embodiment, the CAN bus refers to a spaceborne serial communication bus conforming to the CAN 2.0B specification, with a typical baud rate of 500kbps or 1Mbps; the extended identifier is the 29-bit message identifier field defined by CAN 2.0B, used for arbitration and hardware filtering. The software upgrade file is a sequence of bytes of executable code or configuration data to be uploaded to the receiver, typically in the range of several megabytes. A data block is the application-layer control granularity of the software upgrade file, corresponding to the smallest unit of a single acknowledgment feedback; a base frame is the smallest unit of CAN bus physical layer transmission, with each base frame carrying an 8-byte payload. The sliding window is the upper limit on the number of base frames allowed to be transmitted on the bus before the sender receives an acknowledgment. The acknowledgment frame is a feedback message sent by the receiver after each complete reception of a data block, its payload carrying bit mapping information to characterize the reception status of each base frame within that data block. The offset is the byte position that the receiver has completely received and fixed, updated at the data block level.

[0045] For ease of subsequent description, a typical scenario will be used as an example. In a specific implementation scenario, the onboard CAN bus baud rate is 500kbps, the basic frame payload is 8 bytes, and the software upgrade file size is 2MB, or 2,097,152 bytes. Divided into data block granularities of 256 bytes, the software upgrade file contains a total of 8,192 data blocks; each data block is further divided into 32 basic frames, resulting in a total of 262,144 basic frames in the software upgrade file. The initial window size of the sliding window is set to 16, meaning the sender enters a waiting-for-acknowledgment state after continuously sending 16 basic frames; the initial inter-frame interval between two adjacent basic frames is 0.2ms to accommodate the receiver's hardware filtering and cache writing rhythm. Subsequent numerical examples in various embodiments will all follow this baseline scenario.

[0046] Specifically, each step will be explained in detail below.

[0047] S1. The extended identifier of the CAN bus is re-encoded by bit into source address field, destination address field, frame type field and sequence number field, and the hardware filtering based on the extended identifier switches between point-to-point mode and broadcast distribution mode according to the value of the destination address field.

[0048] The extended identifier specified in the CAN 2.0B standard occupies 29 bits. In this embodiment, these 29 bits are re-encoded into four sub-fields: the source address field occupies the high 8 bits, used to identify the bus node number of the sender; the destination address field occupies the second highest 8 bits, used to identify the bus node number of the intended receiver of this frame; the frame type field occupies the middle 5 bits, used to distinguish message types such as handshake, data, acknowledgment, and termination; and the sequence number field occupies the low 8 bits, used to identify the sequence number of the base frame within this data block. The bit widths of the source address, destination address, and sequence number fields ensure that the sender address space, receiver address space, and base frame number space within a single data block cover 256 nodes and 256 base frames respectively, matching the aforementioned scenario of 32 base frames per data block while reserving expansion space.

[0049] At the hardware filtering level, CAN controllers typically integrate acceptance filters. These filters perform bit-level comparisons of messages transmitted on the bus based on a preset identifier mask, only transferring matching messages to a receive interrupt; mismatched messages are discarded by the controller without triggering CPU action. This application utilizes this mechanism, where the sender dynamically configures the destination address field value and the receiver's filter mask based on the number of objects in the current distribution task. In point-to-point mode, the destination address field is the receiver's unique node number. For example, if the payload computer's node number is 0x12, the sender sets this field to 0x12, and the payload computer's acceptance filter only allows messages with a destination address field equal to 0x12. In broadcast distribution mode, the destination address field is a pre-defined broadcast identifier, such as 0xFF. Multiple receivers' acceptance filters mask all bits of the destination address field, ensuring all receivers receive the message. Since the filtering decision is handled by hardware circuitry, the sender only needs to change the destination address field value when switching between point-to-point and broadcast modes, without modifying the receiver's CPU program logic.

[0050] Although the frame type field occupies only 5 bits, it can be further split into bits to carry auxiliary flags in this embodiment. In some embodiments, the high 2 bits of the frame type field are used to distinguish the main categories of four types of messages: handshake, data, acknowledgment, and end. The encoding method is, for example, 00 for handshake, 01 for data, 10 for acknowledgment, and 11 for end. The low 3 bits carry three flags: "This frame is the first frame of a data block," "This frame is the last frame of a data block," and "This data block is the final data block of the software upgrade file," respectively. In this way, the receiver can directly read the boundary information from the frame type field when processing each basic frame. It can allocate the receive buffer for the next data block in advance without waiting for the arrival of a dedicated end frame, and it can identify the final data block and trigger the upgrade completion process without waiting for the termination frame at the end of the software upgrade file.

[0051] In broadcast distribution mode, since there is only one sender on the bus but there may be multiple receivers, multiple receivers simultaneously returning acknowledgment or denial frames can cause CAN arbitration conflicts. Therefore, in some embodiments, during the handshake phase between the sender and receivers, the sender allocates feedback time slots to several receivers based on the number M of broadcast objects. The allocation rule is to determine the feedback time slot sequence number by taking the remainder of M modulo the destination address of each receiver. After broadcasting a data block, each receiver waits until its corresponding feedback time slot arrives before sending a denial frame; the denial frame carries a bitmap of the receiver's reception status for each basic frame within that data block. After collecting all the denial frames from the receivers, the sender performs a bitwise OR operation on the bitmaps of the receivers to obtain the union. That is, if any receiver marks a basic frame as not received, that basic frame is added to the broadcast retransmission list; basic frames that have been successfully received by all receivers are not retransmitted. Taking a three-receiver scenario as an example, M=3, the destination addresses of payload computer 1, payload computer 2, and payload computer 3 are 0x11, 0x12, and 0x13 respectively, and the modulo results are 2, 0, and 1 respectively. Then the feedback time slot order of the three is payload computer 2, payload computer 3, and payload computer 1.

[0052] S2. Divide the software upgrade file to be distributed into multiple data blocks, and further divide each data block into multiple base frames to obtain a frame sequence of data blocks, wherein each base frame carries a CAN extended identifier message.

[0053] Data blocks and base frames constitute two different granularities: data blocks represent the control granularity of the application layer, corresponding to the receiver's return of an acknowledgment feedback, and also the unit for offset updates and fixation; base frames represent the transmission granularity of the CAN bus physical layer, corresponding to the sender's sliding window advancement. Continuing with the baseline scenario, the software upgrade file size is 2MB, or 2,097,152 bytes. Divided into data blocks of 256 bytes each, the software upgrade file yields 8,192 data blocks. Each data block is further subdivided into 32 base frames, each base frame having a payload of 8 bytes. Therefore, the total number of base frames corresponding to the software upgrade file is 8,192 × 32 = 262,144.

[0054] Each basic frame is encapsulated into a CAN Extended Identifier message before transmission. During encapsulation, the four fields of the extended identifier defined in S1 are filled as follows: the source address field is filled with the sender node number; the destination address field is filled with the receiver node number or broadcast identifier according to the current distribution mode; the frame type field is filled with the data frame identifier and the first / last / final frame flag bits according to the position of this frame within the data block; and the sequence number field is filled with the sequence number of this basic frame within its data block. Taking data block 0 as an example, the 32 basic frames in this data block are numbered 0 to 31 sequentially. The first frame flag bit of the data block in the frame type field is set in the 0th basic frame, the last frame flag bit of the data block is set in the 31st basic frame, and the flag bits of the remaining 30 basic frames are cleared. The 8-byte payload of the 32 basic frames in data block 0 sequentially carries bytes 0 to 255 of the software upgrade file. The basic frames starting from data block 1 follow the same pattern. The sequence number field restarts counting from 0 each time a new data block is entered to avoid overflow due to insufficient bit width of the sequence number field.

[0055] S3. The frame sequence is sent in advance using the sliding window mechanism with the basic frame as the unit. After the sender continuously sends the number of basic frames corresponding to the window size of the sliding window, it does not wait for frame-by-frame acknowledgment. After the receiver receives a data block, it returns an acknowledgment frame. The acknowledgment frame carries bit mapping information that represents the reception status of each basic frame in the data block.

[0056] The sliding window operates on a frame-by-frame basis, meaning that the basic unit allowed for bus transmission within the window is a frame, not a data block. Acknowledgments, on the other hand, are triggered at the data block level; the receiver sends an acknowledgment frame only after receiving all 32 frames of a complete data block. This asynchronous granular design of "frame-by-frame scheduling for transmission and block-by-block feedback for acknowledgments" ensures that the continuous transmission of frame-by-frame transmissions on the bus is not interrupted by frame-by-frame acknowledgment waiting. Furthermore, the number of acknowledgment frames does not increase linearly with the number of frame-by-frame transmissions but is only related to the number of data blocks, significantly reducing the bandwidth consumption caused by feedback traffic.

[0057] Following the baseline scenario, the initial window size is 16, the data block granularity is 32 basic frames, and the software upgrade file contains a total of 8192 data blocks and 262144 basic frames. The sender continuously sends data starting from the 0th basic frame corresponding to the 0th byte of the software upgrade file. For each basic frame sent, a sent but not acknowledged flag is recorded in the sending buffer. When the number of sent but not acknowledged basic frames reaches the window size of 16, the sender enters a waiting state, at which point the sent basic frames exactly cover half of a data block. Because the data block granularity of 32 is larger than the window size of 16, the basic frames within a data block require two window advances to be fully sent—basic frames 0 to 15 are sent in the first window, and basic frames 16 to 31 are sent in the second window. At this point, data block 0 is completely sent, and the sender waits for the receiver to return an acknowledgment frame for data block 0. Each time the receiver successfully receives a basic frame, it sets the corresponding reception status bit. After receiving the last basic frame of data block 0, the receiver organizes the reception status of the 32 basic frames in this data block into bit mapping information, encapsulates it in the payload of the acknowledgment frame, and sends it back to the sender. The sender uses the bit mapping information in the acknowledgment frame to retransmit basic frames marked as not received, and clears basic frames marked as received from the transmission buffer.

[0058] The response frame itself is also a CAN Extended Identifier message. Its frame type field takes the response category, the destination address field is filled with the sender node number, and the payload carries bit mapping information. Since the CAN frame payload is only 8 bytes, the original bitmap required to carry the reception status of 32 basic frames is exactly 4 bytes, or 32 bits. In the current benchmark scenario, the payload space of a single response frame is sufficient. However, once the data block granularity is increased to 64 basic frames or more, the original bitmap will exceed 8 bytes, requiring the introduction of a more compact bit mapping encoding method. This will be discussed in subsequent embodiments.

[0059] In practical applications, packet loss distribution in space links varies significantly across different time periods—the link is stable with extremely low packet loss rates for most of the time, with only short bursts occurring during high-energy particle events or attitude maneuvers. Therefore, in some embodiments, periodic acknowledgments are cancelled during stable link periods. When the receiver detects a jump in the sequence number of a base frame, it actively sends a denial frame. The denial frame carries the base frame interval corresponding to the skipped sequence number to request retransmission. For example, if the receiver receives base frames 0, 1, 2, 3, 5, and 6 sequentially within data block 0, and detects a jump in sequence number from 3 to 5 when receiving base frame 5, skipping 4, it actively sends a denial frame requesting retransmission of base frame 4. Under this mechanism, the feedback overhead of the steady-state link is linearly related to the actual number of packet loss events, rather than the number of data blocks. When the link is extremely stable, the feedback traffic can be reduced to less than one-tenth of that of a conventional periodic acknowledgment scheme.

[0060] As a bit-mapped information organization method adapted to the CAN 8-byte payload constraint, the bit-mapped information in S3 adopts a two-level bitmap encoding: the first-level segment bitmap divides the data block into several segments, and the reception status of each segment is represented by the corresponding bit in the first-level segment bitmap; the second-level frame bitmap only expands the segments represented in the first-level segment bitmap as having an unreceived basic frame, and each bit in the second-level frame bitmap corresponds to the reception status of a basic frame in the corresponding segment; the number of segments ensures that the reception status bit of the basic frame contained in each segment can be accommodated by the remaining bytes in the acknowledgment frame other than the bytes carrying the first-level segment bitmap.

[0061] Specifically, we will take a data block granularity of 32 basic frames in the baseline scenario as an example. If we select 8 segments, each data block is divided into 8 segments, and each segment contains 4 basic frames. The first-level segment bitmap occupies 1 byte (8 bits), with each bit corresponding to one segment: a bit of 1 indicates that all 4 basic frames in the segment have been received completely, and a bit of 0 indicates that at least one basic frame in the segment has not been received. The first byte of the 8-byte response frame payload is allocated to the first-level segment bitmap, and the remaining 7 bytes can carry the second-level frame bitmap. The second-level frame bitmap only expands the segments marked as 0 in the first-level segment bitmap. Each segment's frame bitmap occupies 4 bits, corresponding to the 4 basic frames within the segment; the remaining 7 bytes of payload total 56 bits. In the worst case, all 8 segments expand to 32 bits, still within the 56-bit capacity, which is sufficient for a single response frame.

[0062] When all 32 basic frames of the data block are received completely, all 8 bits of the first-level segment bitmap are set to 1, the second-level frame bitmap does not need to be expanded, and the actual payload of the response frame is only 1 byte. The remaining 7 bytes can be filled with padding bits or reused to carry auxiliary information such as fixed status flags and water level fields. Based on the baseline scenario, the packet loss rate during stable link periods is usually below the speed-up threshold of 1%, and the probability of no frame loss within the data block is close to 100%. The vast majority of response frames fall under this condition, and feedback can be completed with just 1 byte.

[0063] When frames are lost within a data block, the segment bitmap precisely indicates the segment where the lost frame is located, while the frame bitmap only indicates the sequence number of the lost base frame in the corresponding 4 bits of that segment. For example, if base frames 6 and 7 are lost in data block 100, both located in segment 1, which contains base frames 4 to 7, then the first-level segment bitmap is 1011_1111, with segment 1 bits set to 0 and the remaining segment bits set to 1. The second-level frame bitmap only expands the 4 bits of segment 1, resulting in 1100, with the bits corresponding to base frames 6 and 7 in segment 1 set to 0, and the bits corresponding to base frames 4 and 5 set to 1. The first byte of the acknowledgment frame payload contains the segment bitmap, the high 4 bits of the second byte contain the frame bitmap of segment 1, and the remaining bits are unused. After parsing the acknowledgment frame, the sender directly locates the base frames 6 and 7 of data block 100 from the frame bitmap of segment 1 and only retransmits these two base frames.

[0064] If the sender increases the data block granularity to reduce feedback overhead, the number of segments in the two-level bitmap encoding can be adjusted accordingly. For example, when the data block granularity is increased to 64 basic frames, the number of segments remains 8, each segment contains 8 basic frames, the segment bitmap is still 1 byte, and each segment of the intra-segment frame bitmap occupies 1 byte. In the worst case, all 8 segments expand to a total of 8 bytes for the frame bitmap, which exactly fills the response frame payload. The value of the number of segments ensures that the number of bits in each segment frame bitmap multiplied by the worst-case expanded segment number does not exceed the remaining byte capacity of the payload excluding the segment bitmap, thus guaranteeing that the response frame can still be carried by a single frame under the worst-case frame loss distribution.

[0065] The two-level bitmap encoding described above provides compact feedback in random frame loss scenarios, but its efficiency is slightly lower when frame loss occurs in large, continuous segments. In some embodiments, the bitmap information carried in the acknowledgment frame is organized using run-length encoding. The receiving state is represented by an alternating sequence of the number of consecutively received base frames and the number of consecutively unreceived base frames, adapting to the typical burst packet loss distribution of the spatial channel. For example, if base frames 10 to 15 are consecutively lost in data block 100 while the remaining base frames are received, run-length encoding represents the receiving state of this data block as "10 consecutively received, 6 consecutively lost, 16 consecutively received," requiring only 3 bytes to fully express this, which is smaller than the byte size of the two-level bitmap encoding in this burst packet loss scenario. The encoding method can be switched at runtime based on the packet loss distribution characteristics on the link. The switching strategy will be discussed in conjunction with the channel error distribution characteristics in subsequent rate adjustment embodiments.

[0066] In S3, the response frame returned by the receiver also carries a solidification status flag, which is used to characterize whether the receiver is in the data block solidification window period when writing data blocks from random access memory to non-volatile memory.

[0067] The data block persistence window arises from the receiver's storage hierarchy. At the base frame level, the receiver first stores data in the receive buffer of random access memory (RAM). Only after a data block is fully received and passes verification is it written in batches to non-volatile memory (NRAM) to prevent data loss in the event of power failure. NRAM erase / write operations are performed in fixed-number units of bytes, with a single erase / write operation lasting between 10ms and 50ms, significantly longer than the write time of RAM. For example, with a data block granularity of 256 bytes, a single data block persistence operation takes approximately 20ms. During this 20ms period, the receiver is busy writing to NRAM and cannot receive new base frames. If the sender continues transmitting at the original rate, the receiver's buffer will immediately overflow.

[0068] The data block persistence flag is carried in a single bit of the acknowledgment frame. A value of 1 indicates that the receiver is persisting the data block, while a value of 0 indicates that the receiver is idle and ready to receive. The sender checks this flag each time it receives an acknowledgment frame. When the flag is 1, it stops sending the base frame containing the software upgrade file bytes to the receiver, preventing buffer overflow. However, the sender doesn't wait in vain for the 20ms data block persistence window; instead, it switches to prefetch mode. In prefetch mode, the sender sends the receiver a metadata frame for the next data block. This metadata frame carries the sequence number of the next data block, the number of base frames it contains, and the corresponding offset. The frame type field of the metadata frame uses a separate metadata category identifier, enabling the receiver's CAN controller to identify it as a metadata frame rather than a regular data frame at the hardware filtering level, and receive it with minimal interrupt handling overhead. The metadata frame does not need to be written to the receive buffer; it only needs to be stored in the CPU registers or a small amount of random access memory, without affecting parallel non-volatile memory writes.

[0069] Following the baseline scenario, after the receiver fully receives all 32 basic frames of data block 100 and sends an acknowledgment frame for data block 100, it enters a solidification window for data block 100, and the solidification status flag in the acknowledgment frame is set to 1. In the next transmission window after receiving this acknowledgment frame, the sender does not transmit basic frames 0 to 15 of data block 101, but instead sends a metadata frame. This metadata frame carries the next data block sequence number 101, the number of basic frames it contains (32), and a cumulative offset of 101 × 256 = 25856 bytes, indicating that the corresponding byte position for data block 100 has been completed. The receiver, during the solidification of data block 100, receives this metadata frame and only needs to fill a few status register positions in the random access memory with information such as "Data block 101 is about to be received, preparing a receive buffer for 32 basic frames, current cumulative offset 25856 bytes". Approximately 20ms later, the receiver completes the data block solidification of data block 100, the solidification status flag in the response frame flips to 0, and when the next basic frame arrives, the receiver does not need to perform buffer allocation and sequence number field initialization again, and directly enters the basic frame receiving state machine of data block 101.

[0070] This mechanism transforms the data block solidification window of the receiver from a completely idle transmission gap into an effective context prefetching period. The reception connection between data blocks is shortened from a serial process of "solidification completed → waiting for the next base frame to arrive → allocating reception context → starting reception" to a parallel process of "solidification completed → reception context ready → immediate reception". This is equivalent to compressing the switching gap between data blocks from the 20ms level to the base frame interval of 0.2ms.

[0071] In S2, the frame sequence of each data block ends with an end frame. The end frame carries a triple, which includes the starting sequence number of the next data block, the number of base frames contained in the next data block, and the offset accumulated to the current data block.

[0072] Like the aforementioned data frames and response frames, the end frame is a CAN extended identifier message. Its frame type field takes the end category, and the payload carries a triplet. Continuing with the baseline scenario, the end frame corresponding to data block 100 is located after the 32nd base frame of that data block and is sent separately as the last frame of the frame sequence. The triplet it carries is the next data block start number 101, the number of base frames in the next data block (32), and the cumulative offset (25856 bytes). Even if the number of base frames in the next data block is the same as the current data block, this value is still explicitly carried in the triplet instead of being a default value, so as to accurately transmit to the receiver when the link condition changes, such as the case where the rate adjustment of S4 causes the data block granularity to shrink dynamically.

[0073] The end frame not only marks the completion of data block 100 but also serves as the anchor point for the receive context of data block 101. Upon receiving the end frame during normal operation, the receiver initializes the receive context for the next data block with triplet information, including: allocating a new receive buffer in random access memory, resetting the expected frame sequence number to 0, and updating the accumulated offset to the new value in the triplet. Thus, even if any software-state anomaly occurs at the boundary between data blocks 100 and 101, as long as the receiver can continue to receive the end frame, the reception of the next data block does not depend on the historical accumulated state.

[0074] Receiver restart events are an unavoidable phenomenon in spaceborne embedded systems. Common triggers include Single Event Upset (SEU) errors caused by single-event upsets, watchdog timer timeouts, and latch-up protective resets caused by high-energy particle events. A restart event causes the loss of the receiver context in the receiver's random access memory, specifically including the sequence number of the currently received data block, the count of received base frames, the base frame receive status bitmap, and the cumulative offset. Without the end-frame mechanism of this embodiment, the receiver needs to perform a handshake with the sender after restarting—the receiver reports "I have restarted, please inform me of the current progress," and the sender replies "Currently distributing data block N, cumulative offset X." The receiver then reconstructs the receiver context based on this information. The entire handshake takes at least 1 second on a 500kbps bus.

[0075] In this embodiment, the receiver, upon receiving any end frame after its own restart event, initializes the receiving context for the next data block based on the triplet carried by the end frame and resumes the receiving frame sequence. After restarting, the receiver directly enters the "waiting for end frame" state machine without actively initiating a handshake with the sender. The sender continues to send data block 100, end frame 100, data block 101, end frame 101, etc., according to a predetermined rhythm. From the moment the restart is completed, the receiver passively listens to the bus, skipping all basic frames before the first end frame after the handshake. Upon receiving the end frame (e.g., end frame 100), it directly initializes the receiving context for data block 101 with its triplet and resumes reception from the 0th basic frame of data block 101. Since the transmission time of a single data block plus the end frame on a 500kbps bus is approximately 5ms, the longest waiting time for the receiver to resume reception after restarting is no more than approximately 5ms, which is two orders of magnitude shorter than the 1s of the traditional handshake.

[0076] It is worth noting that this restart recovery mechanism and the S5 breakpoint resume mechanism target different scenarios: this mechanism is for situations where the receiver restarts itself but the bus link is not interrupted and the sender is unaware of it; the recovery action is completed unilaterally by the receiver and does not require the sender's cooperation. The S5 breakpoint resume mechanism, on the other hand, is for situations where distribution is interrupted and the sender is aware of it, such as when the link loss is detected by the sender; in this case, the sender actively initiates an offset query to restore the connection. The two mechanisms complement each other.

[0077] S4. Based on the return delay of the acknowledgment frame and the packet loss rate reflected by the bit mapping information, dynamically adjust the window size of the sliding window and the inter-frame interval between two adjacent base frames of the sender.

[0078] The return delay of the acknowledgment frame is defined as the time difference between the sender sending the last base frame of a data block and receiving the corresponding acknowledgment frame, reflecting the sum of the round-trip delay on the link and the receiver's processing delay. The packet loss rate reflected by the bit mapping information is defined as the ratio of the number of unreceived base frames indicated by the bit mapping information in the acknowledgment frame to the total number of base frames for that data block, reflecting the instantaneous frame loss situation on the link. The sender maintains time series of two observations as input for rate adjustment decisions.

[0079] Rate adjustment operates simultaneously in two dimensions. The first dimension is the size of the sliding window—the window size determines the number of base frames that the sender concurrently transmits on the bus, thus determining the link's concurrency and the receiver's instantaneous buffer pressure. The second dimension is the inter-frame interval between two adjacent base frames—the inter-frame interval determines the sender's instantaneous transmission rate, thus determining the link's instantaneous bandwidth occupancy and the receiver's immediate processing pressure. The coordinated adjustment of these two dimensions allows rate adjustment to balance concurrency control and instantaneous rate control. The specific triggering conditions and adjustment step sizes will be elaborated in the next embodiment in conjunction with sub-steps S41 to S44.

[0080] Besides serving as a subjective measure for rate adjustment, the time series trend of acknowledgment frame return delay can also provide a precursor signal of link deterioration. In some embodiments, the sender records the acknowledgment frame return delay sequence for multiple consecutive data blocks. In response to a continuously rising trend in the acknowledgment frame return delay sequence, the sender slightly reduces the sliding window size before packet loss occurs, extending rate adjustment from post-event triggering based on packet loss to pre-event triggering based on delay gradient. For example, if the sender maintains the acknowledgment frame return delays for the most recent four data blocks as 3.5ms, 3.8ms, 4.2ms, and 4.6ms, and the delay sequence shows a monotonically increasing trend with a cumulative increase of 1.1ms, it is determined that there is a precursor to link congestion. Even if the packet loss rate reflected by the bit mapping information is still 0 at this time, the sender slightly reduces the window size from 16 to 15, sacrificing a small amount of throughput for a stability margin in the link state.

[0081] The implementation of bitmap encoding on the receiver side also needs to consider embedded resource constraints. In some embodiments, the receiver uses the remainder obtained by taking the modulo of the sliding window size with the base frame sequence number as the bitmap index to maintain the base frame reception state. The bitmap size adjusts with the sliding window size but does not change with the data block size, thus keeping the memory occupied by the receiver's base frame reception state bitmap within a small range. Continuing with the baseline scenario, the window size is 16, the bitmap is 16 bits long, and it occupies 2 bytes of random access memory. If this indexing method is not used, the receiver needs to reserve one status bit for each of the 32 base frames in each data block, and the bitmap occupies 4 bytes of random access memory. Although the difference between the two is not large in the baseline scenario, when the data block granularity is expanded to 64 or 128 base frames, the latter expands to 8 or 16 bytes, while the former, which uses the sequence number modulo window indexing method, always maintains 2 bytes. The difference is significant on spaceborne embedded receivers where resources are extremely limited.

[0082] Different causes of link degradation necessitate different rate adjustment strategies. In some embodiments, the sender maintains the base frame check failure distribution characteristics reflected in the acknowledgment frames. In response to an increase in the proportion of burst check failures in the distribution characteristics, it selects run-length encoding to organize bit mapping information and adopts a more conservative sliding window size; in response to an increase in the proportion of random check failures in the distribution characteristics, it selects two-level bitmap encoding to organize bit mapping information and adopts a more aggressive sliding window size. Burst check failures refer to errors occurring concentratedly across several consecutive base frame sequence numbers, typically caused by transient interference due to high-energy particle events or attitude maneuvers; random check failures refer to errors occurring scattered across base frame sequence numbers, typically caused by steady-state thermal noise or weak electromagnetic interference. Continuing with the baseline scenario, the sender statistically analyzes the check failure distribution characteristics every 50 data blocks. If the proportion of burst failures exceeds 70%, it switches to run-length encoding feedback and reduces the window size to 8; if the proportion of random failures exceeds 70%, it maintains two-level bitmap feedback and keeps or increases the window size to 20. The sender's understanding of the channel has evolved from "only looking at the packet loss rate" to "packet loss rate plus error type distribution," and the rate adjustment response has evolved from blindly responding to targeted responses.

[0083] Specifically, S4 includes sub-steps S41-S44.

[0084] S41. Obtain the packet loss rate from the statistical bit mapping information, and compare the packet loss rate with the preset speed-up threshold and speed-down threshold. The speed-up threshold is less than the speed-down threshold.

[0085] The acceleration threshold is the criterion by which the sender determines that the link is idle and can expand the window; the deceleration threshold is the criterion by which the sender determines that the link is congested and needs to shrink the window. Following the baseline scenario, the acceleration threshold is set to 1%, and the deceleration threshold to 5%. Since the acceleration threshold is smaller than the deceleration threshold, there is a 4% buffer band between them. When the packet loss rate falls within this buffer band, the sender neither accelerates nor decelerates, avoiding rate oscillations caused by packet loss rate fluctuations near a single threshold.

[0086] S42. In response to the packet loss rate exceeding the deceleration threshold, the window size of the sliding window is reduced by a preset ratio, and the inter-frame interval is increased by a preset increment.

[0087] In this embodiment, the reduction of the window size by a preset ratio is specifically implemented as multiplicative attenuation—the current window size is multiplied by the preset attenuation ratio and then rounded down to obtain the new window size. Continuing with the baseline scenario, the preset attenuation ratio is set to 0.5. If the current window size is 16 and the packet loss rate is 8%, exceeding the 5% rate-reduction threshold, the sender updates the window size to 16 × 0.5 = 8, and simultaneously doubles the inter-frame interval by a preset increment of 0.2 ms, updating the inter-frame interval from 0.2 ms to 0.4 ms. Multiplicative attenuation rapidly halves the concurrency under congestion, and the additive increase in the inter-frame interval immediately halves the instantaneous transmission rate. The combined effect of these two factors significantly reduces the instantaneous basic frame throughput on the bus, quickly alleviating link pressure.

[0088] Following the above operating conditions, in some embodiments, in S42, while reducing the window size of the sliding window by a preset ratio, the number of basic frames contained in the data block is simultaneously reduced. This allows the data block fragmentation granularity to shrink synchronously when the link deteriorates, further improving the timeliness of feedback from the first-level segment bitmap and the second-level frame bitmap. For example, if the original data block granularity was 32 basic frames, it is synchronously reduced to 16 basic frames when the packet loss rate triggers a speed reduction. The number of basic frames covered by the acknowledgment frame corresponding to each data block is halved, the receiver's feedback cycle is doubled, and the sender's response speed to retransmitted lost frames is correspondingly improved.

[0089] S43. In response to a packet loss rate that is lower than the ramp-up threshold and continues for a preset number of response cycles, increase the window size of the sliding window by a preset increment, while keeping the inter-frame interval unchanged.

[0090] The acceleration strategy employs an additive growth approach, adding only a preset increment, such as 1, to the window size each time, rather than using a multiplicative increase symmetrical to the deceleration. This asymmetric design ensures a gentle and gradual window expansion after link recovery, avoiding aggressive window enlargement due to a temporary low packet loss rate that could trigger congestion again. Continuing with the baseline scenario, the current window size is 8, obtained from the aforementioned S42 deceleration. The packet loss rate is 0.3%, lower than the acceleration threshold of 1%. The sender must observe that the packet loss rate remains below the acceleration threshold for a preset number of response cycles before initiating acceleration—the preset number is 5, meaning that when the packet loss rate reflected in the response frames of 5 consecutive data blocks is below 1%, the window size is updated to 9. If the packet loss rate of any response frame exceeds the acceleration threshold during this period, the count is reset to zero and restarts. The inter-frame interval remains at its current value during acceleration, namely the 0.4ms obtained from S42, until multiple acceleration rounds are completed, at which point the decision to restore it to the initial value of 0.2ms is made based on the link's stability.

[0091] Following the above operating conditions, in some embodiments, in S43, while increasing the window size of the sliding window by a preset increment, the number of basic frames contained in the data block is simultaneously increased. This allows the data block fragmentation granularity to be synchronously amplified as the link improves, reducing the total number of response frames per unit software upgrade file length. For example, when the window size is increased back to 16, the data block granularity synchronously recovers from 16 basic frames to 32 basic frames. Each response frame corresponds to feedback information from more basic frames, halving the number of response frames per unit file length and further compressing the feedback overhead.

[0092] S44. In response to a packet loss rate between an acceleration threshold and a deceleration threshold, the window size and inter-frame interval of the sliding window remain unchanged.

[0093] When the packet loss rate falls within the 1% to 5% buffer range, the sender determines that the link is in a stable state and neither increases nor decreases the speed. Continuing with the baseline scenario, with a window size of 16 and an inter-frame interval of 0.2ms, if the packet loss rate is 3%, the current rate level is already tolerable for the link, but the link still experiences some frame drops. For these dropped frames, the sender only performs retransmission based on the bit mapping information without adjusting the rate parameters. This mechanism ensures that the rate parameters are only adjusted when there is a fundamental change in the link state, such as transitioning from a congested state to a stable state, or from a stable state to an idle state. This avoids invalid rate jitter and also avoids the continuous CPU usage of repeated adjustments.

[0094] As a feedforward enhancement to the S4 rate adjustment, the acknowledgment frame returned by the receiver in S3 also carries a water level field representing the remaining capacity of the receive buffer.

[0095] The water level field occupies 1 byte of the response frame payload, with a value ranging from 0 to 100, representing the percentage of remaining capacity in the receiver's receive buffer. Continuing with the baseline scenario, the receiver's receive buffer capacity is 4KB. When 0.8KB of the buffer is used, the water level field is filled with 80, indicating 80% remaining capacity. The water level field is automatically filled by the receiver when encapsulating the response frame; no additional query from the sender is required.

[0096] S4 also includes: dynamically adjusting the acceleration threshold and deceleration threshold according to the water level field; in response to the remaining capacity indicated by the water level field being lower than the preset low water level threshold, lowering the acceleration threshold; in response to the remaining capacity indicated by the water level field being higher than the preset high water level threshold, raising both the acceleration threshold and deceleration threshold.

[0097] The preset low watermark threshold is 20%, and the preset high watermark threshold is 80%. When the watermark field indicates that the remaining capacity is 15%, which is lower than the low watermark threshold of 20%, the sender lowers the ramp-up threshold from the baseline value of 1% to 0.5%, making the sender's ramp-up criteria more stringent—even if the packet loss rate is as low as 0.7%, ramp-up will not be triggered, and the current window size will be maintained to avoid buffer overflow caused by further increasing the window size when the receiver's buffer is tight. When the watermark field indicates that the remaining capacity is 85%, which is higher than the high watermark threshold of 80%, the sender raises the ramp-up threshold from 1% to 2% and the ramp-down threshold from 5% to 8%, making the sender's ramp-down criteria more lenient—even if the packet loss rate rises to 6%, ramp-down will not be triggered, and the current window size will be maintained to maintain high throughput when the receiver's buffer is ample.

[0098] The water level feedback and the packet loss rate feedback in weight 3 complement each other in their mechanism of action. The packet loss rate feedback is a post-event response, meaning that the sender adjusts the rate based on this feedback only after frame loss has occurred. The water level feedback is a pre-event response, meaning that the sender adjusts the threshold based on this feedback even when the receiver's buffer is strained but no frame loss has occurred. The combination of the two extends the response time of rate adjustment from "relying solely on packet loss rate" to a two-dimensional time window of "water level feedforward plus post-event packet loss rate feedback". Continuing with the aforementioned scenario, if the receiver's remaining buffer capacity gradually decreases from 85% to 15%, the sender has already raised the threshold at 85% to relax the rate reduction criterion and lowered the threshold at 15% to tighten the rate increase criterion. This ensures that the rate control parameters have completed a gradual transition from aggressive to conservative before the packet loss rate exceeds the threshold.

[0099] S5. In response to a distribution interruption, obtain the offset information of the data blocks that have been fully received and stored from the receiver, and reinitialize the sliding window from the next data block corresponding to the offset information to resume distribution.

[0100] Typical triggers for data distribution interruptions fall into three categories: The first is link loss events, such as antenna pointing loss due to satellite attitude maneuvers, short-term bus shutdown caused by high-energy particle events during the Earth's shadow period, and protective resets of the receiver-side CAN controller. The second is platform events, such as other high-priority tasks on the satellite preempting bus bandwidth, and temporary CPU resource occupation during attitude control cycles. The third is sender-initiated pauses, such as the issuance of commands from the host computer or a restart by the sender itself. These interruption events are unpredictable in time and vary greatly in duration, ranging from tens of milliseconds to tens of minutes or even longer.

[0101] The receiver's self-rebooting recovery mechanism supported by the aforementioned end-frame triplet addresses the scenario where the bus link remains normal, the sender is unaware, and the receiver unilaterally loses the context. The breakpoint resumption mechanism described in this step addresses the scenario where the sender has detected a link interruption or needs to actively pause. The key difference lies in the initiator of the recovery action—in the former, the receiver passively listens to the end frame and rebuilds the context itself, while in the latter, the sender actively initiates an offset query. This step is necessary because if the sender simply retransmits from the software upgrade file header after the interruption is recovered, a large number of already-hardened data blocks will be repeatedly written to non-volatile memory, wasting bandwidth and accelerating the wear and tear of non-volatile memory. This waste is particularly severe when the interruption occurs near the end of the upgrade process.

[0102] The overall process of resuming interrupted transmission is as follows: After detecting a distribution interruption or active pause, the sender enters an interruption recovery waiting state; when the link is restored or the pause trigger condition is removed, the sender sends an offset query to the receiver, and the receiver returns the cumulative byte position of its last data block in the software upgrade file, i.e., the offset information; based on this, the sender determines the starting data block for recovery, reinitializes the sliding window, and continues sending the frame sequence from the starting data block for recovery. The various sub-steps of the process will be elaborated in the next embodiment.

[0103] Specifically, S5 includes sub-steps S51-S53.

[0104] S51. In response to the recovery request after the distribution interruption, send an offset query request to the receiver.

[0105] The offset query request is a CAN Extended Identifier message. The frame type field is the query subclass under the handshake category, the source address field is the sender node number, and the destination address field is the receiver node number of the task before the breakpoint (point-to-point scenario) or the broadcast identifier (broadcast scenario). The payload of the query request can be empty or carry a 1-byte query sequence number to distinguish multiple queries that may occur in the same recovery process. Continuing from the baseline scenario, if the breakpoint occurs when the sender has sent data block 2000 but it is uncertain which data block the receiver has received, the sender sends an offset query request to the payload computer, carrying the query sequence number 1 within the request.

[0106] S52. Receive offset information returned by the receiver, which indicates the cumulative byte position in the software upgrade file of the last data block that the receiver has fully received and fixed.

[0107] Upon receiving the offset query request, the receiver reads the offset information of the last data block that has been permanently stored in non-volatile memory, encapsulates it into an acknowledgment message, and returns it to the sender. The offset information is expressed in bytes. Continuing with the baseline scenario, if the receiver has completely received and stored data up to data block 1999, the returned offset information will be 2000 × 256 = 512000 bytes, meaning that the byte positions corresponding to 2000 data blocks have been completely received and stored. The total round-trip time of the offset query request and acknowledgment on the 500kbps bus is approximately on the order of 1ms, which is negligible compared to other stages of the entire recovery process.

[0108] S53. Determine the recovery start data block based on the offset information, and reinitialize the sliding window and resume the transmission of the frame sequence starting from the recovery start data block.

[0109] The sender calculates the sequence number of the starting data block to be recovered based on the offset information and data block granularity—the offset of 512,000 bytes divided by the number of data block bytes (256) equals 2000, indicating that 2000 data blocks have been completely received and solidified, corresponding to sequence numbers 0 to 1999. Therefore, the starting data block to be recovered is data block 2000. The sender reinitializes the sliding window starting from the 0th base frame of data block 2000. The window size is restored to the value after the last adjustment before the breakpoint, for example, 8 obtained in S42 or 16 obtained in S43. The inter-frame interval also follows the setting before the breakpoint. From the recovered starting data block, the sender continues to send frame sequences according to the S3 rhythm until the end of the software upgrade file.

[0110] If the offset query request times out without a response, or if the offset information verification field fails, the sender enters a fallback procedure: treating the offset as 0 and resending all data blocks from the software upgrade file header. Although this sacrifices the bandwidth savings of resuming interrupted transmissions, it ensures that the distribution process does not deadlock due to abnormal responses.

[0111] The offset information includes a first offset and a second offset. The first offset is maintained by the receiver in random access memory and is updated each time the receiver fully receives a data block; the second offset is maintained by the receiver in several cyclically written log slots in non-volatile memory and is written to the next log slot with an incrementing version number each time the receiver fully receives a predetermined number of data blocks.

[0112] The first offset and the second offset correspond to two granular levels of the "fixed" concept. It should be noted that the offset fixing mentioned in this step specifically refers to the write operation of offset metadata, which is different from the aforementioned data block fixing—data block fixing refers to the writing of data block content from random access memory to non-volatile memory, triggered once for each data block; offset fixing, on the other hand, uses a lower frequency to protect the erase and write life of non-volatile memory.

[0113] The first offset reflects the complete reception state at the random access memory (RAM) level—the receiver updates the first offset in the RAM immediately after successfully receiving each data block (after all base frames have arrived and the verification passes). The second offset reflects the fixed offset state at the non-volatile memory (NDM) level—the receiver updates the second offset while writing data blocks in batches to the NDM, with an update frequency lower than the first offset. Continuing with the baseline scenario, with a predetermined number of 16 and a cyclic log slot bit width of 8, the receiver updates the first offset in the RAM after each complete reception of a data block; and writes the second offset to the NDM once every 16 complete data blocks received.

[0114] The process of continuously receiving 30 data blocks is used as an example to demonstrate the writing sequence of the circular log. When data blocks 0 to 15 are received, the receiver writes the second offset of 4096 bytes (16 × 256 = 4096) to log slot 0, along with version number 1. When data blocks 16 to 31 are received, the receiver writes the second offset of 8192 bytes to log slot 1, along with version number 2. When data blocks 32 to 47 are received, the receiver writes the second offset of 12288 bytes to log slot 2, along with version number 3. This continues until data blocks 48 to 63 are received, at which point the receiver writes to slot 3 with version number 4. For data blocks 64 to 79, the receiver writes to slot 4 with version number 5. For data blocks 80 to 95, the receiver writes to slot 5 with version number 6. For data blocks 96 to 111, the receiver writes to slot 6 with version number 7. For data blocks 112 to 127, the receiver writes to slot 7 with version number 8. At this point, all eight slots have been written in one round. The next write occurs when data blocks 128 to 143 are received, at which point slot 0 is overwritten, and the version number increments to 9. During recovery, the receiver iterates through 8 slots and reads the second offset recorded in the slot with the largest version number that has passed verification as the authoritative value.

[0115] In S53, the sender responds to the first offset being valid and not less than the second offset by using the next data block corresponding to the first offset as the recovery start data block; in response to the first offset being invalid or less than the second offset, it reads the second offset recorded in the slot with the largest version number and which has passed the verification from several log slots, and uses the next data block corresponding to the second offset as the recovery start data block.

[0116] The recovery strategy behaves differently depending on whether the receiver restarts. Assume that when the interrupt occurs, the receiver has completed receiving all 32 basic frames of data block 2025 and updated the first offset in the random access memory (RAM), but has not yet triggered the offset fixing of the new batch of 16 data blocks from 2016 to 2025. If the receiver has not restarted, the first offset in the RAM remains and is usually greater than the second offset—the first offset is 2026 × 256 = 518656 bytes, meaning that 2026 data blocks have been completely received, corresponding to the byte positions from sequence numbers 0 to 2025. The most recent offset fixing occurred when data block 2015 was received. Based on the predetermined alignment of 16, 2015 = 125 × 16 + 15, meaning 2015 is the last block of the 126th group, triggering one offset fixing. The next offset fixing will be triggered when data block 2031 is received, and the second offset will still be 2016 × 256 = 516096 bytes. In this case, the sender uses the first offset of 518,656 bytes to restore the starting data block to data block 2026. Distribution only needs to continue from data block 2026, and data blocks 2016 to 2025 do not need to be retransmitted. If the receiver has restarted, the first offset may be lost due to power failure or reset of the random access memory, or marked as invalid. The sender then uses the second offset of 516,096 bytes to restore the starting data block to data block 2016. Data blocks 2016 to 2025 need to be retransmitted. Although 10 more data blocks, totaling 2,560 bytes, are transmitted compared to the previous case, the massive redundancy of retransmitting 516,096 bytes from the beginning is avoided.

[0117] The tiered offset fixation scheme significantly reduces the number of non-volatile memory writes compared to a single-layer scheme. Taking an 8192 data blocks in a software upgrade file as an example, if the second offset is fixed once for each data block, a total of 8192 writes are required. After adopting a tiered strategy with a predetermined number of 16, the number of second offset writes is reduced to 8192 / 16 = 512. With the addition of a circular log mechanism, the actual number of erase / write operations for the same non-volatile memory physical unit is 512 / 8 = 64, which is two orders of magnitude lower than the 8192 operations in the single-layer scheme. Considering that the typical erase / write lifespan of commonly used onboard non-volatile memory is on the order of 100,000 cycles, this reduction lowers the non-volatile memory lifespan consumption per upgrade from 0.08% to 0.064%, which is of significant importance for protecting the non-volatile memory lifespan of long-cycle, multi-upgrade tasks.

[0118] The aforementioned hierarchical offset fixation and breakpoint resumption mechanism ensures the recovery capability of the upgrade process itself. However, if the upgrade ultimately fails—for example, if all software upgrade files are received but integrity verification fails—offset information alone is insufficient to revert to the previous running version. Therefore, in some embodiments, as a fallback protection against upgrade failure, the receiver retains a complete image of the current running version in non-volatile memory before the upgrade begins. The boot partition is switched only after all software upgrade files have been received and integrity verification has passed. If the upgrade process ultimately fails or integrity verification fails, the receiver automatically rolls back to the running version corresponding to the complete image and reports to the host computer. Integrity verification is typically completed by comparing the overall hash value of the software upgrade files—the sender informs the receiver of the hash value of the software upgrade files during the handshake phase before initiating the upgrade. After complete reception, the receiver calculates the hash locally and compares it with this value. If the comparison matches, the boot partition is switched; otherwise, a rollback occurs. This mechanism is independent of breakpoint resumption and hierarchical offset fixation, and constitutes a three-layer protection against three different types of abnormal events: temporary disconnection during interruption, receiver restart during interruption, and verification failure at the end of the upgrade.

[0119] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0120] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A CAN bus-oriented satellite-borne software adaptive distribution and control method, which is cooperatively executed by a sender and a receiver, characterized in that, Includes the following steps: S1. The extended identifier of the CAN bus is re-encoded into a source address field, a destination address field, a frame type field, and a sequence number field by bit segment, and the hardware filtering based on the extended identifier switches between point-to-point mode and broadcast distribution mode according to the value of the destination address field. S2. Divide the software upgrade file to be distributed into multiple data blocks, and further divide each data block into multiple basic frames to obtain the frame sequence of the data blocks, wherein each basic frame carries a CAN extended identifier message; S3. The frame sequence is sent in advance using the sliding window mechanism with the basic frame as the unit. After the sender continuously sends the number of basic frames corresponding to the window size of the sliding window, it does not wait for frame-by-frame acknowledgment. After the receiver receives a data block, it returns an acknowledgment frame. The acknowledgment frame carries bit mapping information that characterizes the reception status of each basic frame in the data block. S4. Based on the return delay of the response frame and the packet loss rate reflected by the bit mapping information, dynamically adjust the window size of the sliding window and the inter-frame interval between two adjacent base frames of the sender. S5. In response to a distribution interruption, obtain the offset information of the data block that has been fully received and stored from the receiver, and reinitialize the sliding window from the next data block corresponding to the offset information to resume distribution.

2. The CAN bus oriented on-board software adaptive distribution and control method according to claim 1, characterized in that, The bit mapping information in S3 uses two-level bitmap encoding: The first-level segment bitmap divides the data block into several segments, and the reception status of each segment is represented by a corresponding bit in the first-level segment bitmap. The second-level frame bitmap is only expanded for the segments represented in the first-level segment bitmap as having no received base frames. Each bit in the second-level frame bitmap corresponds to the reception status of a base frame within the segment. The number of segments is such that the receive status bits of the base frame contained in each segment can be accommodated by the remaining bytes in the response frame, excluding the bytes carrying the first-level segment bitmap.

3. The CAN bus oriented on-board software adaptive distribution and control method according to claim 1, characterized in that, S4 includes the following sub-steps: S41. Calculate the packet loss rate by statistically analyzing the bit mapping information, and compare the packet loss rate with a preset acceleration threshold and a deceleration threshold, wherein the acceleration threshold is less than the deceleration threshold; S42. In response to the packet loss rate exceeding the deceleration threshold, the window size of the sliding window is reduced by a preset ratio, and the inter-frame interval is increased by a preset increment. S43. In response to the packet loss rate being lower than the ramp-up threshold and lasting for a preset number of response cycles, the window size of the sliding window is increased by a preset increment, while the inter-frame interval remains unchanged; S44. In response to the packet loss rate being between the acceleration threshold and the deceleration threshold, the window size of the sliding window and the inter-frame interval remain unchanged.

4. The CAN bus oriented on-board software adaptive distribution and control method according to claim 3, characterized in that, In S3, the response frame returned by the receiver also carries a water level field representing the remaining capacity of the receive buffer; S4 further includes: The acceleration threshold and deceleration threshold are dynamically adjusted based on the water level field. In response to the remaining capacity indicated by the water level field being lower than a preset low water level threshold, the acceleration threshold is lowered; in response to the remaining capacity indicated by the water level field being higher than a preset high water level threshold, both the acceleration threshold and the deceleration threshold are raised.

5. The CAN bus oriented on-board software adaptive distribution and control method according to claim 1, characterized in that, S5 includes the following sub-steps: S51. In response to the recovery request after the distribution interruption, send an offset query request to the receiver; S52. Receive offset information returned by the receiver, the offset information indicating the cumulative byte position of the last data block that the receiver has fully received and fixed in the software upgrade file; S53. Determine the recovery start data block based on the offset information, and reinitialize the sliding window and resume the transmission of the frame sequence starting from the recovery start data block.

6. The CAN bus oriented on-board software adaptive distribution and control method according to claim 5, characterized in that, The offset information includes a first offset and a second offset: The first offset is maintained by the receiver in random access memory and is updated each time the receiver fully receives a data block; The second offset is maintained by the receiver in a number of cyclically written log slots in non-volatile memory. The receiver writes the offset to the next log slot and attaches an incrementing version number each time it fully receives a predetermined number of data blocks. In step S53, the sender responds to the first offset being valid and not less than the second offset by using the next data block corresponding to the first offset as the recovery start data block. In response to the first offset being invalid or less than the second offset, the second offset recorded in the slot with the largest version number and which has passed verification is read from the plurality of log slots, and the next data block corresponding to the second offset is used as the recovery starting data block.

7. The CAN bus oriented on-board software adaptive distribution and control method according to claim 6, characterized in that, In S3, the response frame returned by the receiver also carries a solidification status flag, which is used to characterize whether the receiver is in a solidification window period for writing data blocks from random access memory to non-volatile memory. During the execution of S3, in response to the receiver fully receiving a certain data block and the solidification status flag indicating that the receiver is in the solidification window period for solidifying the data block, the sender does not stop sending the frame sequence, but switches to prefetch mode and sends metadata frames of the data blocks following the certain data block to the receiver during the solidification window period. The metadata frames carry the sequence number of the data blocks following the certain data block, the number of basic frames contained therein, and the corresponding offset, so that the receiver can initialize the receiving context of the data blocks following the certain data block based on the metadata frames after solidification is completed.

8. The CAN bus oriented on-board software adaptive distribution and control method according to claim 1, characterized in that, In S2, the end of the frame sequence of each data block contains an end frame, which carries a triplet. The triplet includes the starting sequence number of the next data block, the number of basic frames contained in the next data block, and the offset accumulated to the current data block. During the execution of the S3, the receiver, in response to receiving any one of the end frames after a self-restart event, initializes a receiving context of a next data block based on the triple carried by the end frame, and resumes receiving the frame sequence.

Images