An incremental backup and recovery method and system of configuration parameters of an LED display screen system and a medium

Abstract

The present application relates to a kind of LED display screen system configuration parameter incremental backup and recovery method, system and medium, the method includes: configuration parameter hierarchical modeling and the hash tree construction based on content addressing;According to the hash tree of current configuration generated by the full-amount configuration parameter of LED display screen system current operation, incremental configuration patch package is generated in combination with difference compression algorithm;Configuration parameter is divided into first-level parameter and second-level parameter, first-level parameter is pre-written in the independent shadow storage area of each receiving card local nonvolatile memory;When detecting hierarchical fast recovery process trigger condition, first-level parameter is read from local shadow storage area, and the lighting of basic picture is realized;While in the background, incremental configuration patch package and second-level parameter are applied, and the full-amount configuration is realized without feeling recovery.The present application realizes hierarchical fast recovery after system failure-core parameter second-level local pull-up, full-amount parameter background no-sense completion, improves the disaster recovery capability and operation efficiency of LED display system.

Description

Technical Field

[0001] This invention relates to the field of LED display control and intelligent operation and maintenance technology, and in particular to an incremental backup and recovery method, system and medium for LED display system configuration parameters. Background Technology

[0002] LED display systems (including video processors, transmitting cards, and receiving cards) have a large number of configuration parameters and a complex structure, covering screen physical topology connections, receiver card load area division, video processor signal routing, image enhancement parameters, 3D LUTs (color lookup tables), and massive amounts of point-to-point calibration data. In critical application scenarios such as large-scale performances, live broadcasts, or command centers, the system's stable operation and rapid fault recovery capabilities are crucial.

[0003] The invention patent with authorization announcement number "CN 111382004 B" and titled "Parameter Backup Method and Device, Restore Method and Device and Backup and Restore System" proposes a scheme to generate control commands based on the backup method, obtain the configuration parameters of the controller and receiving card, and generate backup files to be stored in the backup area; the invention patent with authorization announcement number "CN 113377583 A" and titled "Display Controller Backup Method, Device and System" determines paired controllers and performs configuration synchronization by having multiple controllers report parameters; the invention patent with application number "202610275534.8" and titled "Parameter Backup Verification and Abnormal Recovery Method, System and Medium for an LED Synchronous Transmitting Card" adopts a method of collecting all configuration parameters on a timed or on-demand basis, CRC32 verification, time-sequence verification mechanism and hierarchical recovery strategy.

[0004] However, the aforementioned existing technologies still have the following technical defects: 1. Inefficient full backup: The above solutions mostly adopt the full package backup method. Since it contains a large amount of unmodified point-by-point correction data (a single receiving card can have millions of pixels), the backup file size is huge (up to hundreds of MB or even GB), the backup takes a long time, and occupies a lot of storage space. 2. Recovery time remains relatively long: When on-site equipment is damaged and requires emergency replacement, or when system configuration is unexpectedly lost, the existing solution still requires re-sending configuration data from the control terminal via the network. Even with a tiered recovery strategy, due to network transmission delays, serial verification mechanisms, and the need to configure numerous receiver cards one by one, the recovery time for medium to large screens still takes several minutes to tens of minutes, which cannot meet the requirements of second-level recovery in critical scenarios.

[0005] 3. Lack of a precise change identification mechanism: The existing solution fails to establish a refined change tracking system for configuration parameters, making it impossible to accurately identify which specific data blocks have changed, resulting in high backup redundancy.

[0006] 4. Insufficient utilization of local storage resources of the receiving card: The existing solution does not make full use of the non-volatile storage resources (such as Flash / EEPROM) of the receiving card for local preset of key parameters, and still needs to rely on the control terminal to send data during recovery. Summary of the Invention

[0007] This invention provides an incremental backup and second-level recovery method, system, and medium for LED display system configuration parameters. It aims to achieve accurate incremental backup by constructing a content-addressable configuration parameter hash tree, and combine the pre-set core parameters in the local "shadow storage area" of the receiving card with parallel multicast technology to achieve hierarchical and rapid recovery after system failure - core parameters are locally pulled up in seconds, and all parameters are seamlessly completed in the background, thereby improving the disaster recovery capability and operation and maintenance efficiency of the LED display system.

[0008] This invention provides an incremental backup and recovery method for configuration parameters of an LED display system, the method comprising the following steps: Step S10, configuration parameter hierarchical modeling and content-addressed hash tree construction: The configuration parameters of the LED display system are divided into system level, device level, receiver card level, data block level and pixel level. The feature hash value is calculated for the data block at the bottom level. The hash values ​​of all data blocks under the same receiver card are arranged in order and hashed again to generate the node hash value of the receiver card. The hash values ​​are aggregated layer by layer until the system root hash value is generated to build a complete configuration parameter hash tree. Step S20, Incremental Difference Extraction and Patch Package Generation: Upon receiving the backup instruction, a hash tree of the current configuration is generated based on the full configuration parameters of the LED display system currently in operation. The hash tree of the current configuration is compared with the historical baseline hash tree in a depth-first manner, and only the data blocks corresponding to the leaf nodes whose hash values ​​have changed are extracted. An incremental configuration patch package is generated by combining the differential compression algorithm. Step S30, Shadow storage area preset and parameter classification: The configuration parameters are divided into primary parameters and secondary parameters according to their basic and urgency to the screen display. The primary parameters are pre-written into the independent shadow storage area of ​​the local non-volatile memory of each receiving card. Step S40, Hierarchical Fast Recovery and Local Shadow Launch: When the trigger condition of the hierarchical fast recovery process is detected, the receiving card first reads the first-level parameters from the local shadow storage area and takes effect immediately to realize the lighting of the basic screen; at the same time, it receives and applies the incremental configuration patch package and second-level parameters in the background through the multicast protocol to realize the seamless recovery of the full configuration.

[0009] A further technical solution of the present invention is that the step S10 of dividing the configuration parameters of the LED display system into system level, device level, receiver card level, data block level and pixel level includes: dividing the configuration data of each receiver card into several data blocks of a fixed size, wherein the configuration data includes point-by-point correction data.

[0010] A further technical solution of the present invention is that step S20 includes: Step S201: Upon receiving a backup instruction, obtain all configuration parameters of the LED display system currently in operation. Using the layered segmentation rules, bottom-level hash algorithm, and layer-by-layer upward aggregation calculation logic defined in step S10, calculate the current configuration parameters to generate a "current configuration hash tree" containing the system root hash value and the hash values ​​of each level node. The structure of this current configuration hash tree is completely isomorphic to the "historical baseline hash tree" generated during the previous backup. Step S202: Perform a depth-first comparison between the current hash tree and the historical baseline hash tree, comparing the node hash values ​​layer by layer from top to bottom; Step S203: When an inconsistent hash value of a node is detected, traverse downwards until the leaf node that has changed is located; Step S204: Extract only the data blocks corresponding to the leaf nodes whose hash values ​​have changed, and generate an incremental configuration patch package by combining the differential compression algorithm; Step S205: Record the metadata of the incremental configuration patch package and generate a patch package list.

[0011] A further technical solution of the present invention is that the primary parameters in step S30 are basic screen-on parameters, including the receiving card ID, load start coordinates, load resolution, basic splicing relationship and clock phase. The absence of primary parameters will cause the screen to be unable to display any content. Secondary parameters are parameters that enhance image quality, including 3D LUTs, point-by-point correction data, color saturation / contrast / color temperature and other image quality adjustment parameters, and Gamma correction parameters. Even if secondary parameters are missing, the content can still be displayed, but the image quality will not be optimal. Step S30 includes: writing a snapshot of the first-level parameters into an independently designated shadow storage area in the local non-volatile memory of each receiving card via a security instruction. The shadow storage area is physically isolated from the running area and the user configuration area, ensuring that the data in the shadow storage area can still be read even if the data in the running area is corrupted.

[0012] A further technical solution of the present invention is that the triggering conditions for the graded rapid recovery process include: the receiving card power-on self-test detects that the running area configuration data verification fails, the control terminal detects that the device has been replaced and actively issues a recovery trigger command, or the system configuration is unexpectedly lost or damaged.

[0013] A further technical solution of the present invention is that the recovery in step S40 is divided into two stages: the first stage is that the receiving card independently loads the first-level parameters from the local shadow storage area, and the recovery time is less than 1 second; the second stage is that the incremental configuration patch package and the second-level parameters are concurrently distributed through the UDP multicast protocol, and the receiving card updates asynchronously in the background.

[0014] A further technical solution of the present invention is that the first stage in step S40 includes the following steps: Step S401, the receiving card prioritizes and directly reads the "first-level parameters" from the shadow storage area, immediately configures the FPGA / ASIC underlying driver logic, and realizes the second-level lighting of the basic image of the LED screen. The first stage does not rely on any network communication and control terminal data transmission. The second stage includes the following steps: Step S402, Parallel multicast and incremental patch parallel recovery: While the basic screen lights up, the "incremental configuration patch package" and "secondary parameters" are concurrently sent to all receiving cards; the receiving cards receive data asynchronously in the background, and after completing the verification, update the corresponding configuration in the shadow storage area and running memory to achieve seamless recovery of the full configuration.

[0015] A further technical solution of the present invention is that step S402 specifically includes: Step S4021: Establish and maintain a "receiving card-patch package" mapping table. When the second phase is triggered, for receiving cards that need to update their configuration, send the corresponding incremental configuration patch package to all target receiving cards simultaneously through multicast addresses. Step S4022: After receiving the patch package, the receiving card performs an integrity verification. In step S4023, after the verification is successful, the receiving card uses the idle computing power of the FPGA or the background thread of the MCU to decompress the patch package and asynchronously merge it into the running memory and shadow storage area. The current display screen is not interrupted during the merging process, achieving "seamless" recovery.

[0016] To achieve the above objectives, the present invention also proposes an incremental backup and recovery system for LED display system configuration parameters. The system includes a memory, a processor, and an incremental backup and recovery program for LED display system configuration parameters stored in the memory. The incremental backup and recovery program for LED display system configuration parameters is executed by the processor to perform the steps of the method described above.

[0017] To achieve the above objectives, the present invention also proposes a computer-readable storage medium storing an incremental backup and recovery program for LED display system configuration parameters, wherein the incremental backup and recovery program for LED display system configuration parameters is executed by a processor to perform the steps of the method described above.

[0018] The beneficial effects of the incremental backup and recovery method, system, and medium for LED display system configuration parameters of this invention are: 1. Achieving tiered and rapid recovery to ensure the continuity of critical services: This invention innovatively introduces a local "shadow storage area" mechanism on the receiver card, pre-setting "primary parameters" in the receiver card's local non-volatile memory. In the event of a fault, the receiver card independently completes basic screen loading (<1 second), completely eliminating the dependence on network-based data transmission from the control terminal. Compared to existing technologies that still require obtaining parameters through the network and relying on control terminal data transmission, as well as requiring synchronization between controllers, this invention achieves truly control-terminal-independent local second-level recovery.

[0019] 2. Significantly Reduced Backup Size: Based on the incremental comparison mechanism of hash trees, this invention only backs up the data blocks that have changed. Taking the modification of part of the load coordinates of a single receiver card as an example, traditional solutions require backing up the entire amount of data (up to GB level), while this invention only needs to back up the changed data blocks (KB level), reducing the backup size by more than 90%.

[0020] 3. Precise change identification and tracing: Unlike existing technologies that use a single CRC32 check to verify the entire parameter packet, the hash tree structure of this invention supports top-down depth-first comparison, which can accurately locate changes at the specific data block level and supports tracing and comparison of any historical version.

[0021] 4. Parallel multicast improves recovery efficiency: This invention adopts a multicast / parallel broadcast mechanism, which enables hundreds or thousands of receiving cards to receive incremental data simultaneously, resulting in an exponential improvement in overall recovery efficiency compared to traditional serial transmission.

[0022] 5. Scientific and reasonable parameter hierarchical management: This invention classifies parameters into "basic screen brightness" and "enhanced image quality", which conforms to the actual physical operation logic of LED displays - first ensure the screen is lit, then optimize the image quality, making system resource scheduling more efficient.

[0023] This invention can be widely used in LED display program production, stage performances, live broadcasting, command and control centers and other occasions that have high requirements for system reliability and recovery speed. It has good industrial practical value and broad market prospects. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a preferred embodiment of the incremental backup and recovery method for LED display system configuration parameters of the present invention; Figure 2 This is a detailed flowchart of step S20; Figure 3 This is a detailed flowchart of step S40; Figure 4 This is a detailed flowchart of step S402; Figure 5 This is a schematic diagram of hierarchical modeling of configuration parameters; Figure 6 This is a diagram illustrating the hash tree construction process; Figure 7 This is a schematic diagram of the incremental comparison mechanism; Figure 8 This is a schematic diagram of the shadow memory partitioning and hierarchical loading mechanism of the receiving card; Figure 9 This is a schematic diagram of the interaction process between the control terminal and the receiving card. Figure 10 This is a schematic diagram of the hardware architecture of the incremental backup and recovery system for the configuration parameters of the LED display system of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0026] This invention proposes an incremental backup and recovery method for LED display system configuration parameters, such as... Figure 1 As shown, a preferred embodiment of the incremental backup and recovery method for LED display system configuration parameters of the present invention includes the following steps: Step S10, configuration parameter hierarchical modeling and content-addressed hash tree construction: The configuration parameters of the LED display system are divided into system level, device level, receiver card level, data block level and pixel level. The feature hash value is calculated for the data block at the bottom level. The hash values ​​of all data blocks under the same receiver card are sorted in order and hashed again. The node hash value of the receiver card is generated by using SHA-256 or CRC64 algorithm. The hash values ​​are aggregated layer by layer until the system root hash value is generated, and a complete configuration parameter hash tree (Hash Tree / Merkle Tree) is constructed.

[0027] In this embodiment, the step of dividing the configuration parameters of the LED display system into system level, device level, receiver card level, data block level and pixel level specifically includes: dividing the configuration data (including point-by-point correction data) of each receiver card into several data blocks of a fixed size (such as each block containing correction data of N×N pixels), wherein the configuration data includes point-by-point correction data.

[0028] Unlike existing technologies that use a single CRC32 check to verify the entire parameter packet, this embodiment uses a content-addressed hash tree structure to accurately locate changes in configuration data at any granularity, quickly identifying changed data blocks without scanning the entire configuration.

[0029] Step S20, Incremental Difference Extraction and Patch Package Generation: Upon receiving a backup instruction, a hash tree for the current configuration is generated based on the full configuration parameters of the LED display system. The hash tree for the current configuration is then compared with the historical baseline hash tree using a depth-first comparison. Only the data blocks corresponding to the leaf nodes whose hash values ​​have changed are extracted. An incremental configuration patch package is then generated using a differential compression algorithm.

[0030] Unlike existing technologies that use a single CRC32 check to verify the entire parameter packet, the hash tree structure in this embodiment supports top-down depth-first comparison, which can accurately locate changes at the specific data block level and supports traceability comparison of any historical version, achieving accurate change identification and tracing.

[0031] Furthermore, this embodiment employs a hash-based incremental comparison mechanism, backing up only the changed data blocks, which significantly reduces the backup size. Taking the modification of some load coordinates of a single receiver card as an example, traditional solutions require backing up the entire data (up to GB levels), while this embodiment only needs to back up the changed data blocks (KB levels), reducing the backup size by more than 90%.

[0032] Step S30, Shadow storage area presetting and parameter classification: The configuration parameters are divided into primary parameters and secondary parameters according to their fundamental and urgency to the screen display. The primary parameters are pre-written into the independent shadow storage area of ​​each receiver card's local non-volatile memory. In this embodiment, the local non-volatile memory of each receiver card is divided into at least three independent areas: the running area, the shadow storage area, and the secondary parameter area. The three areas are physically address isolated from each other.

[0033] The primary parameters are the basic screen-on parameters, including the receiver card hardware ID and communication address, load start coordinates (X / Y start position), load resolution (width / height), basic splicing relationship, data group mapping relationship (correspondence between RGB data groups and output ports), clock phase and data enable (OE) polarity, basic refresh rate and scanning mode, etc. The absence of primary parameters will result in the screen being unable to display any content.

[0034] The secondary parameters are image quality enhancement parameters, including 3D LUT color lookup table data, point-by-point brightness correction data and point-by-point chromaticity correction data, image quality adjustment parameters such as color saturation / contrast / color temperature, gamma correction parameters, and low grayscale optimization parameters. Content can still be displayed even without these secondary parameters, but the image quality will not be optimal. In practice, users can customize the range of primary and secondary parameters through the control software to adapt to the needs of different application scenarios.

[0035] After the system is running normally and the configuration is stable, the control terminal writes a snapshot of the primary parameters into a separately designated "shadow storage area" in the local non-volatile memory (such as Flash / EEPROM) of each receiving card via a security command. This shadow storage area is physically isolated from the operating area and the user configuration area, ensuring that the data in the shadow storage area can still be read even if the data in the operating area is corrupted.

[0036] This embodiment classifies the configuration parameters into "basic screen brightness" and "enhanced image quality", which conforms to the actual physical operation logic of LED displays: first ensure the screen is lit, then optimize the image quality, making system resource scheduling more efficient.

[0037] In this embodiment, step S30 specifically includes the following steps: after the system is running normally and the configuration is stable, the control terminal writes a snapshot of the first-level parameters into an independently designated shadow storage area in the local non-volatile memory (such as Flash / EEPROM) of each receiving card through a security instruction. The shadow storage area is physically isolated from the running area and the user configuration area to ensure that the data in the shadow storage area can still be read even if the data in the running area is damaged.

[0038] This embodiment introduces a local "shadow storage area" mechanism on the receiver card, pre-setting "primary parameters" in the receiver card's local non-volatile memory. In the event of a fault, the receiver card independently completes basic screen loading (<1 second), completely eliminating the dependence on network-based data transmission from the control terminal. Compared to existing technologies that require obtaining parameters via the network and relying on control terminal data transmission, as well as requiring synchronization between controllers, this embodiment achieves truly control-terminal-independent local second-level recovery, ensuring the continuity of critical services.

[0039] Step S40, Hierarchical Fast Recovery and Local Shadow Launch: When the trigger condition of the hierarchical fast recovery process is detected, the receiving card first reads the first-level parameters from the local shadow storage area and takes effect immediately, realizing the basic screen lighting in seconds; at the same time, it receives and applies the incremental configuration patch package and second-level parameters in the background through the multicast protocol, realizing the seamless recovery of the full configuration.

[0040] Furthermore, such as Figure 2 As shown, in this embodiment, step S20 specifically includes the following steps: Step S201: Upon receiving a backup instruction, obtain all configuration parameters of the LED display system currently in operation. Using the layered segmentation rules, bottom-level hash algorithm, and layer-by-layer upward aggregation calculation logic defined in step S10, calculate the current configuration parameters to generate a "current configuration hash tree" containing the system root hash value and the hash values ​​of each level node. The structure of the current configuration hash tree is completely isomorphic to the "historical baseline hash tree" generated during the previous backup.

[0041] Step S202: Perform a depth-first comparison between the current hash tree and the historical baseline hash tree, comparing the node hash values ​​layer by layer from top to bottom.

[0042] Step S203: When an inconsistent hash value of a node is detected, traverse downwards until the leaf node (data block) that has changed is located.

[0043] Step S204: Extract only the data blocks corresponding to the leaf nodes whose hash values ​​have changed, and generate an incremental configuration patch package by combining the differential compression algorithm, such as bsdiff or xdelta algorithm.

[0044] Specifically, this differential compression algorithm abstracts the data transformation process into three control commands: "Seek", "Copy", and "Diff", by finding the longest matching sequence between the current data block and the historical baseline data block, thereby greatly reducing the size of the patch package.

[0045] The core mathematical model involved in this differential compression algorithm is as follows: 1. Data block sequence definition Let the historical baseline data block (old version) be represented by the byte sequence D_old, which refers to the original binary data stream of a specific partition (such as the point-to-point calibration data area of ​​a receiver card) when a backup is successfully performed on the LED display system; let the current changed data block (new version) be represented by the byte sequence D_new, which refers to the latest binary data stream actually running in the specific partition at the time the backup is triggered.

[0046] D_old = {d_old_1, d_old_2, ..., d_old_m}; D_new = {d_new_1, d_new_2, ..., d_new_n}; m and n are the total byte lengths of the historical baseline data block D_old and the current change data block D_new, respectively. In an LED point-to-point calibration scenario, if a single card carries 64x64 pixels, each with 16 bits for RGB, then the theoretical maximum value of m and n is typically 64 × 64 × 6 = 24576 bytes.

[0047] d_old_x and d_new_y represent the x-th and y-th basic data units in the D_old and D_new sequences, respectively (usually 1 byte, or a 16-bit half-word as defined by the LED calibration precision).

[0048] 2. Longest Matching Substring Location Model When generating the patch package, the algorithm needs to find the longest continuous sequence in D_old that completely matches the substring in D_new. The matching condition and objective function are as follows: The matching condition is: D_new[i+k] = D_old[j+k], where any k belongs to the interval [0, L-1]. Here, i and j are the starting offset indices in the current changed data block D_new and the historical baseline data block D_old, respectively, used to locate the starting point of the longest matching substring. K is the relative offset variable for the matching traversal, with a value range of [0, L-1], used to verify the matching condition byte by byte.

[0049] The optimization objective is to maximize the matching length L, which refers to the number of consecutive identical bytes in D_new and D_old. A larger L value indicates higher data similarity between the two versions, resulting in better compression.

[0050] 3. Differential control instruction triplet encoding model The operations required to fully reconstruct D_new are divided into T control instruction segments, where T is the total number of control instruction segments, representing the total number of "skip-copy-write" operation loops required to fully restore D_new. Each segment is represented by a control instruction triple I_t (or Cmd_t): I_t = (A_t, C_t, D_t), where t belongs to the interval [1, T]. I_t is the t-th control instruction triplet, which is the smallest logical unit constituting the incremental configuration patch package. D_t is the difference data sequence in the t-th instruction, referring to the byte stream that exists in D_new but cannot be matched in D_old (or the matching cost is higher than direct writing). In LED scenarios, this usually corresponds to the new point-by-point luminance or chromaticity correction value of the replaced module.

[0051] The logic for reconstructing the corresponding segment in D_new using this triple is as follows: Step 1: Skip A_t bytes backward in D_old. A_t is the number of bytes to skip backward in the t-th instruction, indicating how many bytes need to be skipped backward in the old data block D_old from the end of the previous operation to find the starting point of the next matching block.

[0052] Step 2: Copy C_t bytes consecutively from the current position of D_old. C_t is the number of bytes copied in the t-th instruction. It represents the length of consecutive bytes copied directly from the old data block D_old (i.e., L in the formula above). In scenarios where only a portion of the LED screen modules are replaced, the calibration data for the modules that are not replaced is completely consistent, and in this case, the value of C_t will be very large.

[0053] Step 3: Append the difference bytes in D_t directly.

[0054] 4. Patch package size calculation and compression optimization goals The total data size Size(P) of the patch package P is the sum of the byte lengths of all instruction triples after encoding. The differential compression of this invention aims to minimize this size: Size(P) = cumulative (from t=1 to T) [ Len(A_t) + Len(C_t) + Len(D_t) ]; where Len(·) is the encoded byte length function, representing the actual number of physical bytes occupied after the corresponding offset or length value is encoded using variable length encoding (such as VarInt encoding). For example, if A_t = 5, VarInt encoding may only occupy 1 byte; if A_t = 300, it may occupy 2 bytes.

[0055] The optimization objective is to minimize Size(P).

[0056] Step S205: Record the metadata of the incremental configuration patch package and generate a patch package list. The metadata of the incremental configuration patch package includes the changed data block identifier, version number, timestamp, and dependent base version number.

[0057] Furthermore, the triggering conditions for the graded rapid recovery process in step S40 include one of the following: the receiving card's power-on self-test detects a failure in verifying the configuration data of the operating area, the control terminal detects a device replacement and actively issues a recovery trigger command, or the system configuration is unexpectedly lost or damaged.

[0058] The recovery process in step S40 is divided into two stages: the first stage is that the receiving card independently loads the first-level parameters from the local shadow storage area, and the recovery time is less than 1 second; the second stage is that the incremental configuration patch package and the second-level parameters are concurrently distributed through the UDP multicast protocol, and the receiving card updates asynchronously in the background.

[0059] like Figure 3 As shown, the first stage in step S40 includes the following steps: Step S401, the receiving card prioritizes and directly reads the "first-level parameters" from the shadow storage area, immediately configures the FPGA / ASIC underlying driver logic, and realizes the second-level lighting of the basic image of the LED screen. The first stage does not rely on any network communication and control terminal data transmission.

[0060] The second stage includes the following steps: Step S402, Parallel multicast and incremental patch parallel recovery: While the basic screen lights up, the "incremental configuration patch package" and "secondary parameters" are concurrently sent to all receiving cards; the receiving cards receive data asynchronously in the background, and after completing the verification, update the corresponding configuration in the shadow storage area and running memory to achieve seamless recovery of the full configuration.

[0061] The specific recovery process is as follows: First stage (T0 ~ T0+1 seconds): The receiving card prioritizes and directly reads the "Level 1 parameters" from the local "shadow storage area," immediately configures the FPGA / ASIC underlying driver logic, and realizes the basic image of the LED screen lighting up within seconds. This stage does not rely on any network communication or control terminal data transmission.

[0062] Phase Two (T0+1 seconds to background continuous): While the basic screen lights up, the control terminal concurrently sends the "incremental configuration patch package" and "secondary parameters" to all receiving cards via gigabit Ethernet or a proprietary fiber optic network protocol. The receiving cards asynchronously receive the data in the background, complete the verification, and update the corresponding configuration in the shadow storage area and running memory, achieving seamless restoration of the full configuration.

[0063] like Figure 4 As shown, step S402 specifically includes the following steps: Step S4021: Establish and maintain a "receiving card-patch package" mapping table. When the second phase is triggered, for receiving cards that need to update their configuration, send the corresponding incremental configuration patch package to all target receiving cards simultaneously through multicast addresses.

[0064] Step S4022: After receiving the patch package, the receiving card performs an integrity check by comparing the target hash value carried in the patch package with the locally calculated value.

[0065] In this embodiment, after the receiving cartoon receives the incremental configuration patch package through the multicast channel, the integrity verification is performed according to the following steps: 1. Packet header parsing and basic verification: The receiving card first parses the header information of the patch packet and checks whether the "target receiving card ID" matches its own ID. If they match, it extracts the "target data block hash (Target_Hash)" from the packet header and performs a CRC check on the packet header itself to ensure that the metadata has not been corrupted during transmission.

[0066] 2. Dry-Run Reconstruction in Memory To avoid system crashes caused by directly modifying the runtime data in Flash, the receiver card allocates a temporary buffer in its internal RAM. The receiver card reads the corresponding "historical baseline data block" from the local Flash and, in conjunction with the received patch package "payload", performs differential restoration operations (i.e., executes skip, copy, and write instructions) in the temporary buffer to generate "candidate new data blocks".

[0067] 3. Local hash value calculation The receiving card uses the exact same hash algorithm (such as SHA-256) as in step S1 to perform hash calculation on the "candidate new data block" generated in the temporary buffer to obtain the "local hash value (Local_Hash)".

[0068] 4. Hash value comparison and decision-making The receiving card compares the "locally calculated hash value (Local_Hash)" with the "target data block hash value (Target_Hash)" extracted from the packet header bit by bit: Verification passed (Local_Hash == Target_Hash): This proves that the patch package was transmitted completely and the restoration logic is correct. The receiving card then writes the "candidate new data block" to the corresponding partition of the Flash (overwriting old data or writing to the advanced parameter area) and updates the local status flag to "restore successful".

[0069] Verification failure (Local_Hash != Target_Hash): This indicates that there was packet loss, corruption, or recovery error in the data transmission. The receiving card immediately discards the data in the temporary buffer, does not perform any Flash write operations, and maintains the original shadow memory state of the system unchanged.

[0070] In step S4023, after the verification is successful, the receiving card uses the idle computing power of the FPGA or the background thread of the MCU to decompress the patch package and asynchronously merge it into the running memory and shadow storage area. The current display screen is not interrupted during the merging process, achieving "seamless" recovery.

[0071] This embodiment employs a multicast / parallel broadcast mechanism, enabling hundreds or thousands of receiving cards to simultaneously receive incremental data, resulting in an exponential improvement in overall recovery efficiency compared to traditional serial transmission.

[0072] The following combination Figures 5 to 9 The incremental backup and recovery method for the configuration parameters of the LED display system of the present invention is further described in detail.

[0073] I. Incremental Backup Process Based on Hash Tree like Figures 5 to 7 As shown, suppose an LED screen has 100 receiver cards, each containing 1 million points of point-by-point calibration data.

[0074] The system configuration is divided into four layers: system, receiver card layer, data block layer, and single-point pixel layer.

[0075] The system layer represents the system-level configuration of the entire display screen. The receiver card layer represents the overall configuration node for each receiver card. The data block layer divides the 1 million points of calibration data from each receiver card into 100 data blocks, each containing 10,000 points (a 100×100 pixel area) of calibration data. The single-pixel layer: In practical implementation, to balance granularity and overhead, each pixel may not be treated as an independent leaf node; instead, the data block may be the smallest leaf node.

[0076] For each 10,000-point data block, calculate the SHA-256 hash value (CRC64 can also be used to balance efficiency and security), generate 100 leaf node hash values, and aggregate them layer by layer upwards to generate the node hash value of the receiving card, and finally generate the system root hash value.

[0077] When a user only modifies the load coordinates of the 10th data block of the 5th receiver card, the following steps are performed: The system recalculates the hash value of the data block, performs a depth-first comparison between the current hash tree and the historical baseline hash tree, starting from the root node, and finds that the hash value of the 5th receiver card node has changed. It continues to traverse downwards and finally locates the hash value of the 10th data block of the 5th card that has changed. The system extracts only the new data of this data block (approximately 10,000 points of correction data + load coordinate metadata), and combines it with the bsdiff differential compression algorithm and the old data of this data block in the baseline version to generate an "incremental configuration patch package" (usually only a few KB to tens of KB). The patch package metadata is recorded as follows: {Receiver Card ID: 5, Data Block Index: 10, Base Version Number: V100, Target Version Number: V101, Hash Value: xxxx}.

[0078] II. Pre-set and Tiered Fast Recovery Mechanism for Shadow Storage Area like Figure 8 As shown, the Flash memory inside the receiver card is logically divided into three independent areas: the running area, the factor storage area, and the secondary parameter area.

[0079] The Runtime Area stores all configuration parameters for the current running system, which can be read during normal system operation.

[0080] The Shadow Storage Area is a separately designated protected area that stores snapshots of "Level 1 parameters" and is only read by the firmware during the recovery phase. The Level-2 Parameter Area stores "secondary parameters" (such as 3D LUTs, point-by-point correction, and other image quality enhancement parameters).

[0081] During the routine pre-setting phase: After the system is debugged and the configuration is confirmed to be stable, the control terminal writes the "primary parameters" (receiver card ID, load start coordinates X / Y, load resolution width / height, basic splicing relationship, clock phase, etc.) into the "shadow storage area" of each receiver card through specific security instructions. After writing is completed, the firmware reads back and verifies the written data to ensure that the data is written correctly.

[0082] During the fault triggering and graded recovery phase: If the main video processor on site crashes or a new transmission card is replaced, a recovery command is triggered after the network is reconnected.

[0083] Phase 1 (Second-level Local Boot-up): After the receiver card powers on or resets, the bootloader first checks the validity flag of the shadow storage area. If valid, the receiver card does not need to wait for any network data and directly reads the first-level parameters from the local shadow storage area to configure the FPGA underlying driver logic. The LED screen resumes basic display within 0.5 seconds. This phase is completely independent of the control terminal; the screen can still light up even if the control terminal has not yet completed startup or the network has not yet been restored.

[0084] The second phase (seamless background update): Simultaneously with the basic screen lighting up, the new control terminal broadcasts the previously generated "incremental configuration patch package" and data from the "secondary parameter area" (such as 3D LUTs and point-by-point corrections) to all receiving cards via Ethernet UDP multicast protocol. The receiving cards utilize the idle computing power of the FPGA or the background DMA channel of the MCU to asynchronously receive and write the data to the corresponding Flash area during the blanking period of the display scan. The entire process has no impact on the front-end display screen, such as stuttering or flickering. After completing the update, the receiving card reports its completion status to the control terminal.

[0085] III. Performance Comparison of Multicast Concurrency Recovery In a medium-sized LED display system containing 200 receiver cards: Using the traditional serial transmission method, each receiving card requires an average of 2 seconds to complete the configuration transmission and verification, and the total recovery time is approximately 200 × 2 = 400 seconds (about 6.7 minutes). The proposed solution is as follows: In the first stage (local startup in the shadow storage area), basic screen display on all receiving cards is completed in less than 1 second. In the second stage, UDP multicast is used for concurrent distribution, with 200 receiving cards simultaneously receiving incremental configuration patch packages (assuming a total patch package size of 5MB). Network transmission time is less than 2 seconds, and background asynchronous writing time is approximately 3-5 seconds (without affecting display). The total recovery time (until full configuration is complete) is less than 10 seconds, with screen startup time less than 1 second.

[0086] The beneficial effects of the incremental backup and recovery method for LED display system configuration parameters of the present invention are: 1. Achieving tiered and rapid recovery to ensure the continuity of critical services: This invention innovatively introduces a local "shadow storage area" mechanism on the receiver card, pre-setting "primary parameters" in the receiver card's local non-volatile memory. In the event of a fault, the receiver card independently completes basic screen loading (<1 second), completely eliminating the dependence on network-based data transmission from the control terminal. Compared to existing technologies that still require obtaining parameters through the network and relying on control terminal data transmission, as well as requiring synchronization between controllers, this invention achieves truly control-terminal-independent local second-level recovery.

[0087] 2. Significantly Reduced Backup Size: Based on the incremental comparison mechanism of hash trees, this invention only backs up the data blocks that have changed. Taking the modification of part of the load coordinates of a single receiver card as an example, traditional solutions require backing up the entire amount of data (up to GB level), while this invention only needs to back up the changed data blocks (KB level), reducing the backup size by more than 90%.

[0088] 3. Precise change identification and tracing: Unlike existing technologies that use a single CRC32 check to verify the entire parameter packet, the hash tree structure of this invention supports top-down depth-first comparison, which can accurately locate changes at the specific data block level and supports tracing and comparison of any historical version.

[0089] 4. Parallel multicast improves recovery efficiency: This invention adopts a multicast / parallel broadcast mechanism, which enables hundreds or thousands of receiving cards to receive incremental data simultaneously, resulting in an exponential improvement in overall recovery efficiency compared to traditional serial transmission.

[0090] 5. Scientific and reasonable parameter hierarchical management: This invention classifies parameters into "basic screen brightness" and "enhanced image quality", which conforms to the actual physical operation logic of LED displays - first ensure the screen is lit, then optimize the image quality, making system resource scheduling more efficient.

[0091] This invention can be widely used in LED display program production, stage performances, live broadcasting, command and control centers and other occasions that have high requirements for system reliability and recovery speed. It has good industrial practical value and broad market prospects.

[0092] To achieve the above objectives, the present invention also proposes an incremental backup and recovery system for LED display system configuration parameters. The system includes an incremental backup module and a recovery scheduling module deployed at the control terminal, and a shadow storage management module and an asynchronous update module deployed at the receiving card terminal. The incremental backup module is used to perform the following steps: Configuration parameter hierarchical modeling and content-addressable hash tree construction: The configuration parameters of the LED display system are divided into system level, device level, receiver card level, data block level and pixel level. The feature hash value is calculated for the data block at the bottom level. The hash values ​​of all data blocks under the same receiver card are sorted in order and hashed again to generate the node hash value of the receiver card. The hash values ​​are aggregated layer by layer until the system root hash value is generated, and a complete configuration parameter hash tree is constructed. Incremental difference extraction and patch package generation: Upon receiving a backup instruction, a hash tree for the current configuration is generated based on the full configuration parameters of the LED display system. The hash tree for the current configuration is then compared with the historical baseline hash tree using a depth-first comparison. Only the data blocks corresponding to the leaf nodes whose hash values ​​have changed are extracted. An incremental configuration patch package is then generated using a differential compression algorithm.

[0093] The recovery scheduling module and asynchronous update module are used to perform the following steps: In the background, they receive and apply incremental configuration patch packages and secondary parameters via multicast protocol to achieve seamless full configuration recovery. The recovery scheduling module uses the UDP multicast protocol to simultaneously send incremental configuration patch packages to all target receiving cards through a single multicast group address. The asynchronous update module utilizes the idle computing power of the receiving card's FPGA or the background thread of the MCU to complete data writing during the blanking period of the display scan, without interrupting the current display screen.

[0094] The shadow storage management module divides the non-volatile memory of the receiving card into at least three independent areas: a running area, a shadow storage area, and a secondary parameter area. These three areas are physically isolated from each other. The shadow storage module is used to perform the following steps: The configuration parameters are divided into primary parameters and secondary parameters according to their fundamental and critical importance to the screen display. The primary parameters are pre-written into the independent shadow storage area of ​​the local non-volatile memory of each receiving card. When the trigger condition of the graded fast recovery process is detected, the receiving card first reads the first-level parameters from the local shadow storage area and takes effect immediately to realize the lighting of the basic screen.

[0095] like Figure 10As shown, the incremental backup and recovery system for the LED display system configuration parameters also includes a processor 1001, a CPU, a network interface 1004, a user interface 1003, a memory 1005, a communication bus 1002, and an incremental backup and recovery program for the LED display system configuration parameters stored on the processor. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and an input unit such as a keyboard. Optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed RAM or a stable, non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0096] Those skilled in the art will understand that Figure 10 The system structure shown does not constitute a limitation on the system and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0097] like Figure 10 As shown, the memory 1005, which serves as a computer storage medium, may include an operating device, a network communication module, a user interface module, and an incremental backup and recovery program for the LED display system configuration parameters.

[0098] exist Figure 10 In the system shown, the network interface 1004 is mainly used to connect to the network server and communicate with the network server; the user interface 1003 is mainly used to interact with the user terminal and receive user input commands; and the processor 1001 can be used to call the incremental backup and recovery program of the LED display system configuration parameters stored in the memory 1005.

[0099] To achieve the above objectives, the present invention also proposes a computer-readable storage medium storing an incremental backup and recovery program for LED display system configuration parameters. When the processor runs the incremental backup and recovery program for LED display system configuration parameters, it executes the steps of the method described above, which will not be repeated here.

[0100] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for incremental backup and recovery of configuration parameters of an LED display system, characterized in that, The method includes the following steps: Step S10, configuration parameter hierarchical modeling and content-addressed hash tree construction: The configuration parameters of the LED display system are divided into system level, device level, receiver card level, data block level and pixel level. The feature hash value is calculated for the data block at the bottom level. The hash values ​​of all data blocks under the same receiver card are arranged in order and hashed again to generate the node hash value of the receiver card. The hash values ​​are aggregated layer by layer until the system root hash value is generated to build a complete configuration parameter hash tree. Step S20, Incremental Difference Extraction and Patch Package Generation: Upon receiving the backup instruction, a hash tree of the current configuration is generated based on the full configuration parameters of the LED display system currently in operation. The hash tree of the current configuration is compared with the historical baseline hash tree in a depth-first manner, and only the data blocks corresponding to the leaf nodes whose hash values ​​have changed are extracted. An incremental configuration patch package is generated by combining the differential compression algorithm. Step S30, Shadow storage area preset and parameter classification: The configuration parameters are divided into primary parameters and secondary parameters according to their basic and urgency to the screen display. The primary parameters are pre-written into the independent shadow storage area of ​​the local non-volatile memory of each receiving card. Step S40, Hierarchical Fast Recovery and Local Shadow Launch: When the trigger condition of the hierarchical fast recovery process is detected, the receiving card first reads the first-level parameters from the local shadow storage area and takes effect immediately to realize the lighting of the basic screen; at the same time, it receives and applies the incremental configuration patch package and second-level parameters in the background through the multicast protocol to realize the seamless recovery of the full configuration.

2. The incremental backup and recovery method for LED display system configuration parameters according to claim 1, characterized in that, The step S10, which divides the configuration parameters of the LED display system into system-level, device-level, receiver card-level, data block-level, and pixel-level, includes: dividing the configuration data of each receiver card into several data blocks of a fixed size, wherein the configuration data includes point-by-point correction data.

3. The incremental backup and recovery method for LED display system configuration parameters according to claim 2, characterized in that, Step S20 includes: Step S201: Upon receiving a backup instruction, obtain all configuration parameters of the LED display system currently in operation. Using the layered segmentation rules, bottom-level hash algorithm, and layer-by-layer upward aggregation calculation logic defined in step S10, calculate the current configuration parameters to generate a "current configuration hash tree" containing the system root hash value and the hash values ​​of each level node. The structure of this current configuration hash tree is completely isomorphic to the "historical baseline hash tree" generated during the previous backup. Step S202: Perform a depth-first comparison between the current hash tree and the historical baseline hash tree, comparing the node hash values ​​layer by layer from top to bottom; Step S203: When an inconsistent hash value of a node is detected, traverse downwards until the leaf node that has changed is located; Step S204: Extract only the data blocks corresponding to the leaf nodes whose hash values ​​have changed, and generate an incremental configuration patch package by combining the differential compression algorithm; Step S205: Record the metadata of the incremental configuration patch package and generate a patch package list.

4. The incremental backup and recovery method for LED display system configuration parameters according to claim 3, characterized in that, The primary parameters in step S30 are the basic screen-on parameters, including the receiver card ID, load start coordinates, load resolution, basic splicing relationship and clock phase. If the primary parameters are missing, the screen will not be able to display any content. Secondary parameters are parameters that enhance image quality, including 3D LUTs, point-by-point correction data, color saturation / contrast / color temperature and other image quality adjustment parameters, and Gamma correction parameters. Even if secondary parameters are missing, the content can still be displayed, but the image quality will not be optimal. Step S30 includes: writing a snapshot of the first-level parameters into an independently designated shadow storage area in the local non-volatile memory of each receiving card via a security instruction. The shadow storage area is physically isolated from the running area and the user configuration area, ensuring that the data in the shadow storage area can still be read even if the data in the running area is corrupted.

5. The incremental backup and recovery method for LED display system configuration parameters according to claim 4, characterized in that, The triggering conditions for the tiered rapid recovery process include: the receiving card's power-on self-test detects a failure to verify the configuration data in the operating area, the control terminal detects a device replacement and actively issues a recovery trigger command, or the system configuration is unexpectedly lost or damaged.

6. The incremental backup and recovery method for LED display system configuration parameters according to claim 5, characterized in that, The recovery process in step S40 is divided into two stages: the first stage is that the receiving card independently loads the first-level parameters from the local shadow storage area, and the recovery time is less than 1 second. The second phase involves concurrently distributing incremental configuration patch packages and secondary parameters via the UDP multicast protocol, with the receiving card updating asynchronously in the background.

7. The incremental backup and recovery method for LED display system configuration parameters according to claim 6, characterized in that, The first stage in step S40 includes the following steps: Step S401, the receiving card prioritizes and directly "reads" the first-level parameters from the shadow storage area, immediately configures the FPGA / ASIC underlying driver logic, and realizes the second-level lighting of the basic image of the LED screen. The first stage does not rely on any network communication and control terminal data transmission. The second stage includes the following steps: Step S402, Parallel multicast and incremental patch parallel recovery: While the basic screen lights up, the "incremental configuration patch package" and "secondary parameters" are concurrently sent to all receiving cards; the receiving cards receive data asynchronously in the background, and after completing the verification, update the corresponding configuration in the shadow storage area and running memory to achieve seamless recovery of the full configuration.

8. The incremental backup and recovery method for LED display system configuration parameters according to claim 7, characterized in that, Step S402 specifically includes: Step S4021: Establish and maintain a "receiving card-patch package" mapping table. When the second phase is triggered, for receiving cards that need to update their configuration, send the corresponding incremental configuration patch package to all target receiving cards simultaneously through the multicast address. Step S4022: After receiving the patch package, the receiving card performs an integrity verification. In step S4023, after the verification is successful, the receiving card uses the idle computing power of the FPGA or the background thread of the MCU to decompress the patch package and asynchronously merge it into the running memory and shadow storage area. The current display screen is not interrupted during the merging process, achieving "seamless" recovery.

9. An incremental backup and recovery system for LED display screen system configuration parameters, characterized in that, The system includes a memory, a processor, and an incremental backup and recovery program for LED display system configuration parameters stored in the memory. The incremental backup and recovery program for LED display system configuration parameters is executed by the processor to perform the steps of the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an incremental backup and recovery program for LED display system configuration parameters, which, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 8.

Images