A method for automatically restoring TSI module configuration data

Abstract

The application relates to a method for automatically restoring TSI module configuration data, which utilizes a communication forwarding module in a TSI framework to forward a debugging command of an upper computer, simultaneously identifies instructions related to configuration in the debugging command, and leaves backup data of the configuration data locally, so as to finally form a complete backup of configuration data of all modules in the framework; the communication forwarding module is utilized to monitor the working state of other modules in the framework, and to compare whether the type and the configuration data of other modules in the framework are consistent with the type and the configuration data in the local backup data, or whether the configuration data is missing; for the configuration data missing or having differences with the backup configuration data, a debugging command is automatically generated, the backup configuration data is sent to a target module, so that the target module automatically restores the configuration data which should be in the original position; the application can accurately and correctly obtain the configuration data of the original module in the position after a new monitor module is inserted into the framework, and starts monitoring and measuring work according to the configuration data.

Description

[Technical Field]

[0001] This invention belongs to the field of turbine monitoring and protection instrument technology, specifically a method for automatically restoring TSI module configuration data. [Background Technology]

[0002] Turbine Supervisory Instruments (TSI instruments) are one of the key pieces of equipment for ensuring the safe operation of steam turbines. TSI instruments are mainly used to monitor signals such as vibration, displacement, differential expansion, eccentricity, and speed of large rotating machinery. The conventional structure consists of a single instrument frame into which various monitor modules with different functions are inserted to perform signal monitoring, measurement, and alarm functions.

[0003] Early TSI instruments had specific monitor modules for each measured signal, with numerous models and specifications. The advantage of this approach was rapid fault handling; simply replacing the faulty module with one of the same model was sufficient. The disadvantage was that users needed to maintain a reserve of spare parts for each monitor module model, resulting in higher maintenance costs. Later, as monitor modules became more intelligent, a single module could monitor multiple signals simultaneously. However, this increased the power-on preparation time, requiring the download of corresponding configuration data from a host computer based on the monitor module's location. Furthermore, since TSI instruments perform crucial monitoring tasks in the field, downloading incorrect configuration data could lead to serious accidents in the field equipment.

[0004] Providing a method for automatically restoring TSI module configuration data, so that after a new monitor module is inserted into the frame, the configuration data of the original module at that location can be obtained accurately and error-free, and monitoring and measurement work can begin according to that configuration data, would be of great significance. [Summary of the Invention]

[0005] The purpose of this invention is to overcome the above-mentioned shortcomings and provide a method for automatically restoring TSI module configuration data. This method enables the new monitor module to accurately obtain the configuration data of the original module at that location after it is inserted into the frame, and to start monitoring and measurement work according to the configuration data. This can speed up the on-site fault handling process and avoid on-site accidents caused by incorrect configuration data settings.

[0006] To achieve the above objectives, a method for automatically restoring TSI module configuration data is designed, comprising the following steps: 1) Using the communication forwarding module 7 in the TSI framework 6 to forward the debugging commands of the host computer 8, while identifying the configuration-related instructions, and storing the configuration data locally as backup data, ultimately forming a complete backup of the configuration data of all modules in the TSI framework 6; 2) Using the communication forwarding module 7 to monitor the working status of other modules in the TSI framework 6, and comparing whether the model and configuration data of other modules in the framework are consistent with the model and configuration data in the local backup data, or whether the configuration data is missing; 3) For configuration data that is missing or differs from the backup configuration data, a debugging command is automatically generated, and the backup configuration data is sent to the target module, so that the target module automatically restores the configuration data that should be in the original position.

[0007] Furthermore, the communication forwarding module 7 automatically generates debugging commands, causing other modules in the TSI framework 6 to enter working or standby states.

[0008] Furthermore, when comparing two sets of configuration data, the communication forwarding module 7 generates a 128-bit highly discrete feature code based on the configuration data. The communication forwarding module 7 determines whether the two sets of configuration data are consistent by comparing the feature code.

[0009] Furthermore, the communication forwarding module 7 includes a debug instruction forwarding 1, configuration backup data 2, instruction queue 3, busboard communication 4, and frame module monitoring 5. After receiving debug instructions from the host computer 8, the debug instruction forwarding 1 converts them into internal busboard instructions and places them in the busboard instruction queue 3. Simultaneously, it identifies the type of debug instruction; if an instruction related to configuration is found, it extracts the configuration data and updates the configuration backup data 2. The busboard communication 4 continuously accesses the instruction queue 3, and upon finding an instruction, sends it to the busboard communication bus, waits for a response from the target module, writes the response into the instruction's response field, and marks the instruction as completed. Alternatively, if no response is received after a period of waiting, the instruction is marked as having timed out. The frame module monitoring 5 periodically generates instructions for accessing module types and configuration data, places these instructions in the instruction queue 3, and processes them accordingly based on the response status. When it finds that the target module type matches but the configuration data is empty or inconsistent with the local backup, it automatically generates a debug instruction to download configuration data and places the instruction in the instruction queue 3.

[0010] Furthermore, the debugging instruction forwarding 1 includes receiving and processing debugging instructions, identifying and judging instruction types, processing instruction queues, and saving local configuration backups. The receiving and processing of debugging instructions listens for communication data on the Ethernet interface. Once a configuration instruction from the host computer 8 is received, the instruction type is analyzed and identified. If it is an instruction about configuration data, the local configuration backup data is updated according to the instruction. At the same time, the configuration instruction from the host computer 8 is converted into a protocol and added to the instruction queue. If it is not an instruction about configuration data, it is directly converted into a protocol and added to the instruction queue. After being added to the instruction queue, it waits for the instruction to be executed and a response to be received. Finally, the received response is converted and sent to the host computer 8.

[0011] Furthermore, the framework module monitoring 5 includes generating status query commands, waiting for response judgment, recording module status processing, and generating configuration command processing. It periodically generates status query commands for the target module, adds them to the bus board command queue, waits for a response from the target module, and then performs corresponding processing based on the module's response. If the module does not respond, it is considered that there is no module in that slot in the framework, and it is marked as empty in the local status. If the module receives a response and the response type matches, but the configuration is inconsistent with the local backup, a configuration data download command is generated, added to the bus board command queue, and waits for the bus board's command processing to be executed. If the module receives a response and the response type is inconsistent with the local backup, the module type in that slot is marked as incorrect. If the module receives a response and both the response type and configuration data are consistent with the local backup, the module is marked as working normally.

[0012] Furthermore, the busboard communication 4 continuously queries the instruction queue 3 for any unexecuted instructions. If there are any, the instruction is sent to the busboard bus, and then the system waits for a response from the target module on the bus. If a response is received within a specified time, the instruction is marked as executed successfully, and the received response data is recorded. If a response is not received within a specified time, the instruction is marked as executed successfully and timed out. The instruction marked as executed successfully will be taken away by other functions.

[0013] Compared with existing technologies, this invention utilizes the communication forwarding module in the TSI framework to simultaneously forward debugging commands from the host computer and retain a backup of the entire framework's configuration data. By monitoring the working status and configuration data of other modules within the framework, if any module's configuration data is found to be missing or inconsistent with the local backup, the invention proactively downloads the locally backed-up configuration data to the target module. This allows the target module to quickly restore the configuration data that the original module should have and begin normal monitoring and measurement work. Using this method, backup modules do not need to have their configuration data pre-set before powering on, which speeds up on-site fault handling and avoids on-site accidents caused by incorrect configuration data pre-setting. This invention also ensures that when a new monitor module is inserted into the framework, it can accurately obtain the configuration data of the original module at that location and begin monitoring and measurement work according to that configuration data. In summary, by using the automatic TSI module configuration data recovery method described in this invention, when a new TSI monitor module is inserted into the framework to replace the original TSI monitor module, the configuration data in the original monitor module can be automatically restored without manual intervention. The CPU in the module can then begin normal monitoring and measurement work based on this new configuration data. [Image Description]

[0014] Figure 1 This is a schematic diagram illustrating the automatic recovery of configuration data according to the present invention;

[0015] Figure 2 This is a functional structure diagram of the communication forwarding module of the present invention;

[0016] Figure 3 This is a flowchart of the debugging instruction forwarding process of this invention;

[0017] Figure 4 This is a flowchart of the monitoring process for the framework module of this invention;

[0018] In the diagram: 1. Debugging command forwarding; 2. Configuration backup data; 3. Command queue; 4. Busboard communication; 5. Frame module monitoring; 6. TSI frame; 7. Communication forwarding module; 8. Host computer. [Detailed Implementation]

[0019] As attached Figure 1As shown, this invention provides a method for automatically restoring TSI module configuration data. It utilizes the communication forwarding module in the TSI framework to forward debugging commands from the host computer, while simultaneously identifying and backing up configuration data. The communication forwarding module can also monitor the working status of other modules in the framework. For configuration data that is missing or differs from the backed-up configuration data, the backed-up configuration data can be sent to the target module, enabling the target module to automatically restore the configuration data that should be present in its original location. This method for automatically restoring TSI module configuration data mainly includes the following steps: 1) Using the communication forwarding module 7 in the TSI framework 6 to forward debugging commands from the host computer 8, while simultaneously identifying configuration-related instructions and storing backup configuration data locally, ultimately forming a complete backup of the configuration data for all modules in the TSI framework 6; 2) Using the communication forwarding module 7 to monitor the working status of other modules in the TSI framework 6, and comparing the model and configuration data of other modules in the framework with the model and configuration data in the local backup data to determine if they are consistent, or if any configuration data is missing; 3) For configuration data that is missing or differs from the backed-up configuration data, a debugging command is automatically generated, and the backed-up configuration data is sent to the target module, enabling the target module to automatically restore the configuration data that should be present in its original location.

[0020] The main features of this invention are: firstly, it uses the communication forwarding module in the TSI framework to forward the host computer debugging commands, while saving relevant configuration data and retaining backup data; secondly, it monitors the working status of other modules in the framework and can compare the differences between the configuration data in the monitored module and the locally retained data; thirdly, it can automatically generate debugging commands for modules with missing configuration data or discrepancies in the comparison, and send the locally retained configuration data to the module.

[0021] Specifically, while forwarding debugging commands from the host computer, the communication forwarding module can identify configuration-related commands and store configuration data locally as a backup, ultimately forming a complete backup of the configuration data for all modules in the framework. The communication forwarding module can monitor the operating status of other modules, comparing the model and configuration data of other modules in the framework with the locally stored model and configuration data to check for consistency or missing configuration data. Based on the locally backed-up configuration data, the communication forwarding module can automatically generate debugging commands and download local configuration data for other monitor modules with matching models but different or missing configurations. The communication forwarding module can automatically generate debugging commands to put other modules into working or standby states. When comparing two sets of configuration data, the communication forwarding module generates a 128-bit highly discrete feature code based on the configuration data, and uses this feature code to determine whether the two sets of configuration data are consistent.

[0022] The present invention will be further described below with reference to the accompanying drawings and specific embodiments:

[0023] This method for automatically restoring TSI module configuration data can automatically obtain the configuration data of the original module at that location after a new monitor module is added to the TSI framework, and start monitoring and measurement work based on this configuration data. (See attached image) Figure 2 As shown, the automatic recovery method is completed in the communication forwarding module. The communication forwarding module 7 includes debugging instruction forwarding 1, configuration backup data 2, instruction queue 3, bus board communication 4, and frame module monitoring 5.

[0024] A method for automatically restoring TSI module configuration data is supported by three independently operating functions: debug command forwarding, busboard communication, and framework module monitoring. The debug command forwarding function receives debug commands from the host computer, converts them into internal busboard commands, and places them in the busboard command queue 3. It also identifies the type of debug command; if a command is related to configuration, it extracts the configuration data and updates the configuration backup data 2. The busboard communication function continuously accesses the command queue. Upon detecting a command, it sends it to the busboard's communication bus, waits for a response from the target module, writes the response into the command's response field, and marks the command execution as complete. Alternatively, if no response is received after a certain period, the command is marked as having timed out. The framework module monitoring function periodically generates commands to access module types and configuration data, places these commands in the command queue, and processes them accordingly based on the command responses. When a target module type matches but the configuration data is empty or inconsistent with the local backup, a debug command to download configuration data is automatically generated and placed in the command queue. Once the new TSI module is inserted into the rack, as long as its model and specifications match the module in the original position, it can automatically obtain the correct configuration data of the module in that position and begin monitoring and measurement. The entire process requires no manual intervention.

[0025] As attached Figure 3 The diagram illustrates the detailed process of the debug command forwarding function, which mainly includes: receiving and processing debug commands, identifying and judging command types, adding commands to the command queue, and saving local configuration backups. This function receives debug commands by listening for communication data on the Ethernet interface. Once a configuration command is received from the host computer, the command type is analyzed and identified. If the command concerns configuration data, the local configuration backup data is updated accordingly. Simultaneously, the host computer's configuration command is converted to a different protocol and added to the command queue; otherwise, it is directly converted to a different protocol and added to the command queue. After being added to the command queue, the function waits for the command to be executed and for a response to be received. Finally, the received response is converted and sent to the host computer.

[0026] As attached Figure 4The diagram illustrates the detailed process of the framework module monitoring function, which mainly includes: generating status query commands, waiting for response judgment, recording module status processing, and generating configuration command processing. This function periodically generates status query commands for the target module, adds them to the command queue, waits for the target module to respond, and then processes the response accordingly. If the module does not respond, it is assumed that there is no module in that slot in the framework, and it is marked as empty in the local status. If the module receives a response and the response type matches, but the configuration is inconsistent with the local backup, a configuration data download command is generated, added to the command queue, and waits for the bus board's command processing to execute. If the module receives a response and the response type is inconsistent with the local backup, the module type in that slot is marked as incorrect. If the module receives a response and both the response type and configuration data are consistent with the local backup, the module is marked as working normally.

[0027] To expedite the comparison of configuration data, the software can generate a digital signature for the module's configuration data. By comparing the digital signatures of the local configuration and the target module's configuration, it can determine whether the two sets of configuration data are consistent, thus replacing the need to compare all complete configuration data.

[0028] The busbar communication function continuously checks the instruction queue for any unexecuted instructions. If any are found, the instruction is sent to the busbar bus, and then the system waits for a response from the target module on the bus. If a response is received within a specified time, the instruction is marked as executed successfully, and the received response data is recorded. If no response is received within the specified time, the instruction is marked as executed successfully but has timed out. Instructions marked as completed are then retrieved by other functions.

[0029] This invention is not limited to the above-described embodiments. Any changes, modifications, substitutions, combinations, or simplifications made without departing from the spirit and principle of this invention shall be considered equivalent substitutions and shall be included within the scope of protection of this invention.

Claims

1. A method for automatically restoring TSI module configuration data, characterized in that, Includes the following steps: 1) The communication forwarding module (7) in the TSI framework (6) forwards the debugging commands of the host computer (8), identifies the configuration-related instructions, and stores the configuration data locally as backup data, thus forming a complete backup of the configuration data of all modules of the TSI framework (6); 2) Use the communication forwarding module (7) to monitor the working status of other modules in the TSI framework (6), and compare the model and configuration data of other modules in the framework with the model and configuration data in the local backup data to see if they are consistent or if the configuration data is missing. 3) For configuration data that is missing or differs from the backup configuration data, a debugging command is automatically generated to send the backup configuration data to the target module, so that the target module can automatically restore the configuration data that should be in the original location. The communication forwarding module (7) includes a debugging instruction forwarding (1), configuration backup data (2), instruction queue (3), busboard communication (4), and frame module monitoring (5). After receiving the debugging instruction from the host computer (8), the debugging instruction forwarding (1) converts it into an internal busboard instruction and puts it into the instruction queue (3) of the busboard. At the same time, it identifies the type of debugging instruction. If an instruction related to configuration is found, the configuration data is extracted and the configuration backup data (2) is updated. The busboard communication (4) continuously accesses the instruction queue (3). After finding an instruction, it sends it to the communication bus of the busboard, waits for the response from the target module, and writes the response into the response field of the instruction to mark the instruction as completed. Alternatively, if no response is received after a period of waiting, the instruction is marked as a response timeout. The frame module monitoring (5) periodically generates instructions for accessing the module type and configuration data, puts the instructions into the instruction queue (3), and processes them accordingly based on the response of the instructions. When it finds that the target module type matches but the configuration data is empty or inconsistent with the local backup, it automatically generates a debugging instruction for downloading configuration data and puts the instruction into the instruction queue (3).

2. The method for automatically restoring TSI module configuration data as described in claim 1, characterized in that: The communication forwarding module (7) automatically generates debugging commands, causing other modules in the TSI framework (6) to enter working or standby states.

3. The method for automatically restoring TSI module configuration data as described in claim 1, characterized in that: When comparing two sets of configuration data, the communication forwarding module (7) generates a 128-bit highly discrete feature code based on the configuration data. The communication forwarding module (7) determines whether the two sets of configuration data are consistent by comparing the feature code.

4. The method for automatically restoring TSI module configuration data as described in claim 1, characterized in that: The debugging instruction forwarding (1) includes receiving and processing debugging instructions, identifying and judging instruction types, processing instruction queues, and saving local configuration backups. The receiving and processing of debugging instructions listens for communication data on the Ethernet interface. Once a configuration instruction from the host computer (8) is received, the instruction type is analyzed and identified. If it is an instruction about configuration data, the local configuration backup data is updated according to the instruction. At the same time, the configuration instruction from the host computer (8) is converted into a protocol and added to the instruction queue. If it is not an instruction about configuration data, the protocol is directly converted and added to the instruction queue. After being added to the instruction queue, the instruction is waited to be executed and a response is received. Finally, the received response is converted and sent to the host computer (8).

5. The method for automatically restoring TSI module configuration data as described in claim 1, characterized in that: The framework module monitoring (5) includes generating status query instructions, waiting for response judgment, recording module status processing, and generating configuration instruction processing. It periodically generates status query instructions for the target module, adds them to the bus board instruction queue, waits for the target module to give a response, and then performs corresponding processing based on the module's response. If the module does not respond, it is assumed that there is no module in the slot in the framework and marks it as empty in the local status. If the module receives a response and the response type matches but the configuration is inconsistent with the local backup, it generates a configuration data download instruction, adds it to the bus board instruction queue, and waits for the bus board instruction processing to be executed. If the module receives a response and the response type is inconsistent with the local backup, it marks the module type of the slot as incorrect. If a module receives a response and the response type and configuration data are consistent with those locally, then the module is marked as working correctly.

6. The method for automatically restoring TSI module configuration data as described in claim 1, characterized in that: The busboard communication (4) continuously queries the instruction queue (3) for any unexecuted instructions. If there are any, it sends the instructions to the busboard bus and then waits for the response from the target module on the bus. If a response is received within the specified time, the instruction is marked as completed and successful, and the received response data is recorded; if no response is received within the specified time, the instruction is marked as completed and timed out, and the completed instruction will be taken by other functions.

Images