Thread Content
Maintenance and Guidance for Honeywell TPS Control Systems [Abstract] This article covers some basic knowledge regarding the software and hardware maintenance of Honeywell TPS systems, various concepts related to system maintenance as well as relevant tools, and presents some advanced solutions. 【Keywords】 TPS system maintenance, diagnosis, inspection, testing. Introduction: The Honeywell TPS system provides a highly reliable service in industrial environments. Failures are rare but do exist. Failures can be minimized in their impact by being designed to be redundant. Isolation, component separation, and returning the faulty module accelerate the fault detection of software and hardware. I. Maintaining the philosophy An important concept of the TPS system is to ensure its high level of practicality. Increase the average time between failures and normal operation of the system by reducing the average maintenance time. There can be various levels of testing methods; firstly, hardware self-testing can be used to check the most basic function of a module – its ability to load software. Other checks can be tested when loading the “Properties” software. During normal system testing, the testing software continuously checks the functionality of each module and provides recommended maintenance information once issues are detected. While the redundant modules are still operational, effective fault detection and module repair are employed to minimize the impact of the fault on the system. System administrators performing maintenance on the system is the most cost-effective method. Replacing the optimal replacement unit ORU (a certain node or hardware) on-site takes less time than repairing the hardware on-site. II. Maintenance Rules The TPS system has corresponding procedures for dealing with faults in both software and hardware. 1. Concept of self-check. Two-level automatic testing of system modules – hardware self-test and quality logic test – ensures that every component of the system is always ready for operation. Once in service, each corresponding node of the system continuously performs checks, including for internal issues and problems with communication with external devices. When a fault occurs, the faulty module automatically exits service mode and provides a corresponding recommendation to the US printer. 2. Module startup test. When the power is turned on or the module’s “reset button” is pressed, the diagnostic light indicates whether the module can load its corresponding “attributes” from the LCN network. When a fault on the circuit board is detected, the module stops operating, and the fault is displayed on a 3-digit LED. If the test is successful, the module displays its status and waits for the property software that loads it. The next phase of startup testing is to evaluate the performance of QLT (Quality Logic Testing). These tests will further examine the functionality of the module and leave corresponding status information for subsequent inspection. 3. Normal operation test. There are many types of routine operation tests: continuous operation tests, input/output communication tests, and peripheral checks such as printers and drives. 4. Fault information. Each LCN module can generate various hardware error messages, which are then displayed or printed out via the US. For example, the latest module maintenance information can be found in US’s MAINT INFO. 5. Maintain recommended information. The Maintenance Recommendation Message (MRM) is a special type of fault report generated by on-process software; it includes real-time information as well as maintenance status visible from the US. The content of MRM varies depending on the environment, but the purpose of each piece of information is to help users resolve the problems they encounter. In some cases, the recommended information requires additional testing. 6. In-process analysis. For a system with HM, the on-process on HM provides an additional diagnostic function. OPA (in process analysis) checks the cumulative data of each module on the LCN network. OPA runs at least every 8 hours, and it is executed when the accumulated error confidence reaches 75% of the error buffer. 7. GUS maintenance attributes. The maintenance attributes include the engineer attributes of GUS. Maintaining attributes is achieved by selecting SMCC/Maintance. Module Memory – Displays the memory of the active LCN node. System Maintenance Journal – Shows historical information on maintenance activities. Rev/config status – Displays the version status (hardware, software, firmware). Hiway box memory – Shows the memory of the selected High-way box. Sector init./reassign – Initializes or reassigns the problematic sectors on the SCSI drive. Active maint journal – Displays currently relevant recommendations and keeps a record of performed actions. Probe failed module – Shows the memory of a module that is not functioning properly. Module error – Displays errors stored in the module, provided both in a summary and in detail. 8. Other service tools. HVTS can test many modules simultaneously and independently, including the CPU, memory, or LCN communication between modules. HVTS is a testing program for acquisition; each module contains some small programs, but they can be used universally with certain LCN modules. These testing procedures are divided into many separate parts; using HVTS requires a GUS (for test loading and control), and both the node under test and other nodes must cease operating. Independent testing requires that all nodes under test be disconnected from the LCN network. III. System Diagnosis When a hardware failure occurs in a module or Hiway Box of a TPS system, check the LEDs to identify the cause of the problem. When an error is detected, it is quite important to collect as much information as possible. When an error is detected, the processing steps can be carried out in the following order: For general faults, the following sequence applies: 1. Check the fault indicator. When deciding which ORU needs to be replaced, it is necessary to know the type of failure. The number on the LED provides important information. By loading the GUS maintenance attributes, error messages from the current and past can be obtained, and all recommendations from that time can be accessed. 2. Before attempting to test the problematic module, the node should be shut down first, and the module removed. This ensures that there is no conflict with modules that are still in use. In the event of an unnecessary alarm. 3. Testing. If more testing is required, this problem module can be installed using appropriate offline testing software. In some cases, it is necessary to physically isolate the module from the active LCN network. 4. ORU replacement. Module removal and ORU. 5. The module is reinstalled in the service. Once these isolated modules are powered on again and pass the inspection, they will be able to return to operational status and have their property software reloaded. 6. Enter the correct operation information. Enter the correct operation information to view the current maintenance recommendations and restart the fault accumulator of (ORU). What to do when the cause of the fault cannot be determined: (1) If the system or module does not function properly but it is still allowed to be used. 1. Record all fault symptoms and the user’s actions prior to the fault, including the types of operations performed on the system. Such as: regional database configuration, station setup, display of trend charts, etc. 2. Record the attributes that are being used. Such as: engineers, operators, AM, HM, etc. 3. Record the system software version number. It can be found on HONEYWELL’s system disk. 4. Record all error messages. Real-time logs or historical records during failures. 5. If custom displays or user-written programs are included, copy all flowcharts, related subgraphs, or CL programs. (II) If the node does not respond: 1. Record all fault symptoms and the user’s actions prior to the fault, including the types of operations performed on the system. Such as: regional database configuration, station setup, display of trend charts, etc. 1. Record the attributes that are being used. Such as: engineers, operators, AM, HM, etc. 2. Record the system software version number. It can be found on HONEYWELL’s system disk. 3. Record all error messages. Real-time logs or historical records during failures. 4. If custom displays or user-written programs are included, copy all flowcharts, related subgraphs, or CL programs. 5. Record the status display on the LED; if the board fails, the red light will turn on, and all such red lights should be recorded. 6. Record the digital display on the LED; it usually shows the node number, and a negative number will be displayed if that occurs. 7. Use the engineer attribute maintenance function to display the module details of all faulty nodes, and print using CTRL+END. 8. Dump sufficient memory from the nodes to HM’s &2NP or floppy disk. 9. Provide an at least 2-page real-time magazine on faults; if no such magazine is available, print out the historical events prior to and during the fault. 10. If a hard drive failure is suspected, run the corresponding HVTS software. If the faulty node is HG and the LED displays –189 or –195, use the engineer attribute maintenance function to display all faulty modules in HG.