Method for realizing OPS backup and restoration based on serial communication

Abstract

This invention relates to the field of embedded system communication technology, and in particular to a method for OPS backup and restore based on serial communication. This method is applied to a serial communication control scenario between a first device and a second device, wherein the first device is an OPS module or an embedded terminal, and the second device is an interactive electronic tablet or a centralized control terminal. The method includes: initializing the serial communication interface and configuring the initial baud rate; sending a query data frame to obtain the operation command returned by the second device; performing valid frame search and multi-layer verification on the received data; dynamically switching the baud rate and retrying when receiving abnormalities; and writing a backup identifier, a restore identifier, or a clear identifier in a preset data exchange area according to the parsed operation command. This invention does not rely on a keyboard or network environment and can automatically trigger and reliably confirm the OPS backup and restore process through a serial port. It has advantages such as high communication robustness, high degree of automation, and suitability for batch deployment and on-site maintenance.

Description

Technical Field

[0001] This invention relates to the field of embedded system communication technology, specifically to a method for OPS backup and restore based on serial communication. Background Technology

[0002] In applications such as smart commercial displays, educational terminals, industrial control, and pluggable computing modules, OPS modules typically undertake functions such as system computing, application operation, and data processing. System backup and restoration are important means to ensure system reliability. When the system fails, or when users make mistakes and the system is deployed in batches, it is crucial to be able to quickly and accurately restore to the preset system.

[0003] The existing technical solutions still have shortcomings, specifically: the existing backup and restore solutions based on keyboard shortcuts are highly complex to operate: users need to accurately grasp the timing of key presses, which can easily lead to missing the best trigger time; they are highly dependent on human intervention: operators must be present and manually intervene, making it impossible to achieve remote or automated operation; they have low deployment efficiency: in batch device deployment scenarios, keyboard operation is required for each device, which is time-consuming and labor-intensive; they have high device dependence: in front-line scenarios, keyboards may not be available; and they have poor user experience, high operating threshold, and are prone to misoperation. Network-based remote backup and restore solutions, on the other hand, have several drawbacks. They are highly dependent on the network: they require a stable network environment and server infrastructure; they have high deployment costs: they need to set up dedicated network boot servers, DHCP servers, TFTP servers, etc.; they pose significant security risks; they can complicate the network topology; and when the system crashes, network services are usually unavailable. Furthermore, firmware support for network protocols can significantly increase the initialization time at each boot, reducing the user experience. Summary of the Invention

[0004] The purpose of this invention is to provide a method for OPS backup and restore based on serial communication, so as to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A method for OPS backup and restore based on serial communication includes the following steps: S1, Hardware configuration-aware serial link initialization: During the startup phase, the first device reads the hardware configuration or board-level identification information, determines the resource mapping relationship of the target serial port controller, and initializes parameters such as baud rate, data bits, stop bits, parity bits, and receive FIFO for the UART controller. By introducing a hardware configuration awareness mechanism, the method of the present invention can adapt to the differences in serial port resources under different hardware implementations, reduce the adaptation complexity caused by changes in hardware configuration, and thus improve the adaptability, engineering portability, and actual deployment flexibility of the method. S2, Data frame query and response parsing based on a preset protocol: The first device constructs a query data frame according to a preset communication protocol and sends it to the second device via a serial port to obtain the target operation command returned by the second device. After receiving the response data, the first device performs a valid data frame search and field validity verification in its local receive buffer. The field validity verification includes one or more of the following: frame header identifier verification, length field verification, fixed identification code verification, command type verification, subcommand matching verification, and frame tail identifier verification. Through the valid data frame identification and verification mechanism, it is possible to handle situations such as uncertain frame boundaries, noise byte mixing, and interference from historical residual data during asynchronous serial communication, thereby improving the accuracy of target operation command parsing and the reliability of the communication process. S3, a valid response frame identification mechanism based on multi-layer field validation: The field validity verification includes at least two or more of the following: frame header identifier verification, length field verification, fixed identification code verification, frame tail identifier verification, command type verification, and subcommand matching verification. The first device performs the above multi-layer field matching on the candidate data frames to filter out valid response frames that meet the preset format constraints, and extracts the corresponding operation instructions or confirmation results after successful identification. Compared with the method of judging based on only a single frame header or length field, the multi-layer field verification mechanism can reduce the probability of false identification and improve the ability to filter out abnormal byte streams, irrelevant response data, and incomplete data frames, thereby improving the reliability of serial port protocol parsing. S4, Query retry and preset baud rate switching mechanism based on anomaly judgment: During the receiving process, the first device combines the receiving timeout situation, the valid response frame identification result, and the invalid byte statistics result to determine the current serial communication status. When it is detected that no valid response frame is received within a preset time, the received result does not meet the valid frame identification condition, or the received data meets the preset anomaly judgment condition, the query is determined to have failed. For the failure situation, the first device re-initiates the query according to the preset retry rules. When the preset baud rate switching condition is met, the first device switches to another preset baud rate and reinitializes the UART controller before executing the query again. When the preset maximum number of retries is reached, the communication failure result is returned. Through this mechanism, the success rate of obtaining a valid response and the fault tolerance of the communication process can be improved in the case of a single query failure or differences in serial port parameters. S5, a phased processing mechanism based on the write of the recovery control flag: After the first device parses and obtains the backup command, restore command, or clear command, it writes the corresponding recovery control identifier into a preset data exchange area. This allows subsequent recovery modules to read and execute the corresponding operations in later processing stages, instead of completing the entire recovery process directly within the current serial port processing flow. This method separates the triggering of the recovery operation from its execution, thereby reducing the complexity of the current communication processing flow. S6, a serial port closed-loop control mechanism based on acknowledgment responses: After completing the status identifier writing, the first device constructs an acknowledgment data frame and sends it to the second device. Subsequently, it receives an acknowledgment response from the second device. The first device performs valid frame identification and field verification on the acknowledgment response, corresponding to the aforementioned response parsing process. After the acknowledgment verification passes, it extracts the result information to determine whether the preset acknowledgment process has been completed. By introducing an acknowledgment response mechanism, a closed-loop verification can be formed for the aforementioned query triggering and status writing process, thereby reducing the risk of repeated triggering caused by communication anomalies, incomplete responses, or untimely status updates, and improving the consistency and confirmability of the serial port control process.

[0006] As a preferred embodiment of the present invention, the operation method of S1-S6 is applied to the communication scenario between the OPS module as the first device and the second device. The first device can be the OPS module or an embedded terminal, and the second device can be an interactive electronic tablet or a centralized control terminal. The system automatic backup and restore function of the first device is realized through the serial port, without the need for a keyboard or network connection, and the operation is completed solely by the serial port.

[0007] As a preferred embodiment of the present invention, the UART controller parameters in step S1 include at least baud rate, data bits, stop bits, and parity bits; in some embodiments, it may also include receive FIFO enable state or receive depth configuration. During the startup phase, the first device determines the resource mapping relationship of the target serial port controller according to the hardware configuration or board-level identification result, and completes the initialization of the corresponding serial port parameters to establish a serial communication link with the second device.

[0008] As a preferred embodiment of the present invention, the query data frame in step S2 includes at least a frame header identifier, a data length field, a fixed identification code, a query type identifier, a query subcommand, and a frame tail identifier. The first device preferably clears the receiving buffer before sending the query data frame to reduce the impact of historical residual data on the current response parsing result. Through the preset protocol format composed of fixed fields and command fields, the first device can actively obtain the target operation instruction returned by the second device.

[0009] As a preferred embodiment of the present invention, the field validity verification in step S3 includes at least two or more of the following: frame header identifier verification, length field verification, fixed identification code verification, frame tail identifier verification, command type verification, and subcommand matching verification. The first device performs a valid data frame search on the received data in the local buffer, and only identifies the candidate data frame as a valid response frame and extracts the operation instructions or confirmation results therein when the candidate data frame meets the preset field matching conditions. Through the multi-layer field verification mechanism, the accuracy of target response identification in asynchronous serial communication scenarios can be improved. As a preferred embodiment of the present invention, the number of invalid bytes in S3 is the number of bytes that do not conform to the frame header identifier.

[0010] As a preferred embodiment of the present invention, the invalid bytes in step S3 are data bytes that do not meet the preset frame header identification conditions in the received data stream, or data bytes that meet the frame header conditions but fail the subsequent field verification. The first device counts the invalid bytes and, in conjunction with the reception timeout situation and the valid response frame identification result, determines the current communication status. When the received data meets the preset abnormal conditions, the query retry process in step S4 can be triggered, and if necessary, the preset baud rate switch can be performed.

[0011] As a preferred embodiment of the present invention, the baud rate switching in step S4 is a switching operation between preset candidate baud rates. After determining that the query has failed, the first device re-initiates the query according to the preset retry rules. When the preset baud rate switching conditions are met, the first device switches to another preset baud rate and reinitializes the UART controller before executing the query again. If no valid response is obtained within the preset maximum number of retries, a communication failure result is returned.

[0012] As a preferred embodiment of the present invention, the preset data exchange area in step S5 is a state storage area for storing recovery control identifiers, which are written to by the current processing stage and read by the subsequent recovery execution stage. The recovery control identifiers include at least one or more of backup identifiers, restore identifiers, and clear identifiers. After parsing the corresponding operation instructions, the first device writes the corresponding identifiers into the data exchange area to realize the phased processing of operation triggering and subsequent recovery execution.

[0013] As a preferred embodiment of the present invention, the confirmation data frame in step S6 includes at least a frame header identifier, a data length field, a fixed identification code, a setting type identifier, a setting sub-command, operation data, and a frame tail identifier. After completing the status identifier writing, the first device sends the confirmation data frame to the second device via a serial port and receives the confirmation response returned by the second device. The first device performs valid frame identification and field verification corresponding to step S3 on the confirmation response, and extracts the result information after the verification is successful to determine whether the preset confirmation process has been completed.

[0014] As a preferred embodiment of the present invention, the second device has serial communication capability and control interaction capability, used to receive query data frames or confirmation data frames sent by the first device, and return response data corresponding to the current control state; the first device has serial port transmission and reception capability, protocol parsing and status identifier writing capability, used to initiate communication requests, identify target operation instructions and complete subsequent control processes.

[0015] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention establishes a preset serial communication protocol and combines it with a closed-loop processing mechanism for valid data frame identification, query retry, preset baud rate switching, and confirmation response. This enables reliable interaction of backup and restore control commands between the first and second devices. The triggering and confirmation of OPS backup and restore operations can be completed without relying on a keyboard or network environment, thereby improving the reliability of the communication process, the automation of the system recovery process, and the convenience of on-site deployment and maintenance. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the process of the present invention; Figure 2 This is a schematic diagram of the module interaction of the present invention; Figure 3 This is a schematic diagram of the communication timing of the present invention. Detailed Implementation

[0017] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0018] To facilitate understanding of the present invention, a more comprehensive description of the invention will be given below with reference to the accompanying drawings, and several embodiments of the invention will be provided. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of the present invention will be more thorough and complete.

[0019] For examples, please refer to Figure 1-3 The present invention provides a technical solution: A method for OPS backup and restore based on serial communication includes the following steps: In this embodiment, the first device first reads the hardware configuration or board-level identification information to determine the resource mapping relationship of the target serial port controller, and then initializes the UART controller. The initialization parameters include at least the baud rate, data bits, stop bits, parity bits, and receive FIFO-related parameters. Through this initialization process, a serial communication link is established between the first device and the second device.

[0020] After serial port initialization is complete, the first device constructs a query data frame according to a preset protocol format. The query data frame includes at least a frame header identifier, a data length field, a fixed identification code, a query type identifier, a query subcommand, and a frame tail identifier. Preferably, before sending the query data frame, the first device clears the receive buffer to reduce the impact of historical residual data on the parsing of the current response. Subsequently, the first device sends the query data frame to the second device via the UART serial port and starts the receive timing.

[0021] The first device receives data returned by the second device within a preset time and writes the received data into its local buffer. Since data may arrive continuously during asynchronous serial communication and the frame start position is not fixed, the first device does not directly treat all received content as a valid result. Instead, it performs a valid data frame search and field validity check in its local buffer. The field validity check includes at least two or more of the following: frame header identifier check, length field check, fixed identification code check, frame tail identifier check, command type check, and subcommand matching check. Only when a candidate data frame meets the preset field matching conditions is the first device identified as a valid response frame and extracts the operation instructions or confirmation results from it. This method improves the accuracy of target response identification.

[0022] During the receiving and parsing process, the first device counts invalid bytes and, combined with the receiving timeout and valid response frame identification results, determines the current serial communication status. If no valid response frame is received within a preset time, the received result does not meet the valid frame identification conditions, or the received data meets preset anomaly judgment conditions, the query is deemed a failure. In response to this failure, the first device re-initiates the query according to preset retry rules; if the preset baud rate switching conditions are met, the first device switches to another preset baud rate, reinitializes the UART controller, and executes the query again. If no valid response is obtained within the preset maximum number of retries, a communication failure result is returned. This method can improve the success rate of obtaining a valid response even in cases of a single failed query or differences in serial port parameters.

[0023] After the first device parses and receives a backup command, restore command, or clear command, it does not directly execute the complete backup or restore process during the current serial communication process. Instead, it writes the recovery control identifier corresponding to the operation command into a preset data exchange area. This data exchange area is used to transfer control status between the current processing stage and the subsequent recovery execution stage, so that the subsequent recovery module can read and execute the corresponding operation in the subsequent processing stage. This method separates the operation triggering process from the recovery execution process, thereby reducing the complexity of the current communication processing flow.

[0024] After completing the write of the recovery control identifier, the first device further constructs an acknowledgment data frame and sends it to the second device. The acknowledgment data frame includes at least a frame header identifier, a data length field, a fixed identification code, a setting type identifier, a setting sub-command, operation data, and a frame tail identifier. Upon receiving the acknowledgment response from the second device, the first device performs valid frame identification and field verification corresponding to the aforementioned response parsing process. After successful verification, it extracts the result information to determine whether the preset acknowledgment process has been completed. By introducing acknowledgment response processing, a closed-loop verification can be formed for the aforementioned query triggering and status writing processes, thereby reducing the risk of repeated triggering and improving the consistency of the serial port control process.

[0025] In a preferred embodiment, during the startup phase, the first device selects a target serial port controller based on the board-level identification result and completes UART initialization at a preset initial baud rate. It then sends a query data frame to the second device to obtain the currently pending operation command. When the first device parses a backup command from a valid response frame, it writes a backup identifier into a preset data exchange area; when it parses a restore command, it writes a restore identifier into the data exchange area; and when it parses a clear command, it performs the corresponding clearing process. After writing the identifier, the first device sends an acknowledgment data frame to the second device and determines whether the preset acknowledgment process has been completed based on the acknowledgment response returned by the second device.

[0026] All standard parts used in this application can be purchased from the market. The specific connection methods of each part adopt conventional methods such as bolts, rivets, and welding that are mature in the prior art. The machinery, parts and equipment adopt conventional models in the prior art and are also general components, which are common knowledge in this field.

[0027] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for realizing OPS backup and restoration based on serial port communication, characterized in that, Includes the following steps: S1, Hardware configuration-aware serial link initialization: During the startup phase, the first device reads the hardware configuration or board-level identification information, determines the resource mapping relationship of the target serial port controller, and initializes parameters such as baud rate, data bits, stop bits, parity bits, and receive FIFO for the UART controller. By introducing a hardware configuration awareness mechanism, the method of the present invention can adapt to the differences in serial port resources under different hardware implementations, reduce the adaptation complexity caused by changes in hardware configuration, and thus improve the adaptability, engineering portability, and actual deployment flexibility of the method. S2, Data frame query and response parsing based on a preset protocol: The first device constructs a query data frame according to a preset communication protocol and sends it to the second device via a serial port to obtain the target operation command returned by the second device. After receiving the response data, the first device performs a valid data frame search and field validity verification in its local receive buffer. The field validity verification includes one or more of the following: frame header identifier verification, length field verification, fixed identification code verification, command type verification, subcommand matching verification, and frame tail identifier verification. Through the valid data frame identification and verification mechanism, it is possible to handle situations such as uncertain frame boundaries, noise byte mixing, and interference from historical residual data during asynchronous serial communication, thereby improving the accuracy of target operation command parsing and the reliability of the communication process. S3, a valid response frame identification mechanism based on multi-layer field validation: The field validity verification includes at least two or more of the following: frame header identifier verification, length field verification, fixed identification code verification, frame tail identifier verification, command type verification, and subcommand matching verification. The first device performs the above multi-layer field matching on the candidate data frames to filter out valid response frames that meet the preset format constraints, and extracts the corresponding operation instructions or confirmation results after successful identification. Compared with the method of judging based on only a single frame header or length field, the multi-layer field verification mechanism can reduce the probability of false identification and improve the ability to filter out abnormal byte streams, irrelevant response data, and incomplete data frames, thereby improving the reliability of serial port protocol parsing. S4, Query retry and preset baud rate switching mechanism based on anomaly determination: During the receiving process, the first device combines the receiving timeout situation, the valid response frame identification result, and the invalid byte statistics result to determine the current serial communication status. When it is detected that no valid response frame is received within a preset time, the receiving result does not meet the valid frame identification condition, or the received data meets the preset anomaly determination condition, the query is determined to have failed. For the failure situation, the first device re-initiates the query according to the preset retry rules; when the preset baud rate switching condition is met, the first device switches to another preset baud rate and reinitializes the UART controller before executing the query again. When the preset maximum number of retries is reached, a communication failure result is returned. This mechanism can improve the success rate of obtaining a valid response and the fault tolerance of the communication process in the event of a failed query or a difference in serial port parameters. S5, a phased processing mechanism based on the write of the recovery control flag: After the first device parses and obtains the backup command, restore command, or clear command, it writes the corresponding recovery control identifier into a preset data exchange area. This allows subsequent recovery modules to read and execute the corresponding operations in later processing stages, instead of completing the entire recovery process directly within the current serial port processing flow. This method separates the triggering of the recovery operation from its execution, thereby reducing the complexity of the current communication processing flow. S6, a serial port closed-loop control mechanism based on acknowledgment responses: After completing the status identifier writing, the first device constructs an acknowledgment data frame and sends it to the second device. Subsequently, it receives an acknowledgment response from the second device. The first device performs valid frame identification and field verification on the acknowledgment response, corresponding to the aforementioned response parsing process. After the acknowledgment verification passes, it extracts the result information to determine whether the preset acknowledgment process has been completed. By introducing an acknowledgment response mechanism, a closed-loop verification can be formed for the aforementioned query triggering and status writing process, thereby reducing the risk of repeated triggering caused by communication anomalies, incomplete responses, or untimely status updates, and improving the consistency and confirmability of the serial port control process.

2. The method for realizing OPS backup and restoration based on serial communication according to claim 1, characterized in that: The operation methods described in S1-S6 are applied in a communication scenario where the OPS module acts as the first device and the second device. The first device can be the OPS module or an embedded terminal, and the second device can be an interactive electronic tablet or a centralized control terminal. The first device can automatically back up and restore its system via a serial port, without the need for a keyboard or network connection, and can complete the operation solely through the serial port.

3. The method for realizing OPS backup and restoration based on serial communication according to claim 1, characterized in that: The UART controller parameters in step S1 include at least baud rate, data bits, stop bits, and parity bits; in some embodiments, they may also include receive FIFO enable state or receive depth configuration. During the startup phase, the first device determines the resource mapping relationship of the target serial port controller based on the hardware configuration or board-level identification result, and completes the initialization of the corresponding serial port parameters to establish a serial communication link with the second device.

4. The method for realizing OPS backup and restoration based on serial communication according to claim 1, characterized in that: The query data frame in step S2 includes at least a frame header identifier, a data length field, a fixed identification code, a query type identifier, a query subcommand, and a frame tail identifier. The first device preferably clears the receiving buffer before sending the query data frame to reduce the impact of historical residual data on the current response parsing result. Through the preset protocol format consisting of fixed fields and command fields, the first device can actively obtain the target operation instruction returned by the second device.

5. The method for realizing OPS backup and restoration based on serial communication according to claim 1, characterized in that: As a preferred embodiment of the present invention, the field validity verification in step S3 includes at least two or more of the following: frame header identifier verification, length field verification, fixed identification code verification, frame tail identifier verification, command type verification, and subcommand matching verification. The first device performs a valid data frame search on the received data in the local buffer, and only identifies the candidate data frame as a valid response frame and extracts the operation instructions or confirmation results therein when the candidate data frame meets the preset field matching conditions. Through the multi-layer field verification mechanism, the accuracy of target response identification in asynchronous serial communication scenarios can be improved. As a preferred embodiment of the present invention, the number of invalid bytes in S3 is the number of bytes that do not conform to the frame header identifier.

6. The method for realizing OPS backup and restoration based on serial communication according to claim 1, characterized in that: As a preferred embodiment of the present invention, the invalid bytes in step S3 are data bytes that do not meet the preset frame header identification conditions in the received data stream, or data bytes that meet the frame header conditions but fail the subsequent field verification. The first device counts the invalid bytes and, in conjunction with the reception timeout situation and the valid response frame identification result, determines the current communication status. When the received data meets the preset abnormal conditions, the query retry process in step S4 can be triggered, and if necessary, the preset baud rate switch can be performed.

7. The method for realizing OPS backup and restoration based on serial communication according to claim 1, characterized in that: As a preferred embodiment of the present invention, the baud rate switching in step S4 is a switching operation between preset candidate baud rates. After determining that the query has failed, the first device re-initiates the query according to the preset retry rules. When the preset baud rate switching conditions are met, the first device switches to another preset baud rate and reinitializes the UART controller before executing the query again. If no valid response is obtained within the preset maximum number of retries, a communication failure result is returned.

8. The method for realizing OPS backup and restoration based on serial communication according to claim 1, characterized in that: As a preferred embodiment of the present invention, the preset data exchange area in step S5 is a state storage area for storing recovery control identifiers, which are written to by the current processing stage and read by the subsequent recovery execution stage. The recovery control identifiers include at least one or more of backup identifiers, restore identifiers, and clear identifiers. After parsing the corresponding operation instructions, the first device writes the corresponding identifiers into the data exchange area to realize the phased processing of operation triggering and subsequent recovery execution.

9. The method for OPS backup and restore based on serial communication according to claim 1, characterized in that: The confirmation data frame in step S6 includes at least a frame header identifier, a data length field, a fixed identification code, a setting type identifier, a setting sub-command, operation data, and a frame tail identifier. After completing the status identifier writing, the first device sends the confirmation data frame to the second device via a serial port and receives the confirmation response returned by the second device. The first device performs valid frame identification and field verification corresponding to step S3 on the confirmation response, and extracts the result information after the verification is successful to determine whether the preset confirmation process has been completed.

10. The method for OPS backup and restore based on serial communication according to claim 1, characterized in that: The second device has serial communication capability and control interaction capability, and is used to receive query data frames or confirmation data frames sent by the first device, and return response data corresponding to the current control status; The first device has serial port transmission and reception capabilities, protocol parsing capabilities, and status identifier writing capabilities, which are used to initiate communication requests, identify target operation commands, and complete subsequent control processes.

Images