Thread Content
Case 4: Failure to conduct interlock protection tests led to the shutdown of the unit. I. Fault phenomenon: At 21:22 on August 27, 2016, the ethylene compressor at a chemical company suddenly shut down due to an interlock shutdown during operation. II. Cause analysis: (1) Investigations following the accident revealed that the process operators failed to detect in time that the lubricating oil filter was clogged, resulting in an excessive pressure difference before and after the filter. This led to low lubricating oil pressure, which in turn triggered the unit’s protection mechanisms. (2) Another reason for that shutdown was a defect in the interlock logic: there are two lubricating oil pumps, and when the oil pressure drops, the other pump should start immediately; however, the logic causes the other pump to start after a 6-second delay. The testing team and the personnel from the chemical company failed to carry out the interlock tests as required during the testing process and before starting up the unit, thus missing several opportunities to identify defects in the protection logic. III. Identified issues: (1) Operators fail to properly monitor critical parameters, failing to detect problems in a timely manner and address them promptly. (2) During the infrastructure commissioning process, the relevant maintenance personnel did not participate earnestly. (3) The company’s interlock protection testing is not conducted in a proper manner, with insufficient oversight. IV. Preventive measures: (1) Process operators should strengthen monitoring of key process parameters and record them in a timely manner. (2) Strictly implement the test requirements for interlock protection, formulate rigorous interlock protection test sheets, and standardize test procedures to ensure safety ; Important protection signals such as valve opening or closing, motor start or stop, high or low pressure, and high or low liquid level must be strictly implemented.
I didn’t pay attention during debugging, and problems arose when using it
The pump should be started immediately, but I wonder why a 6-second delay was added in the initial logic design. It’s unlikely that it was added by the configuration staff; surely it was suggested by someone from the process team. You should investigate the reason behind adding this 6-second delay. The above are just my personal thoughts
Yes, the pump should be started immediately. It was done by the configuration staff. The original design called for the pump to start immediately and stop after a 6-second delay, but the configuration was incorrect – the pump now starts after a 6-second delay instead.
Damn, they can do this without debugging – what boldness:D
This case actually exposes many management issues: 1) no simulation and debugging during configuration, 2) no joint testing before operation, 3) no regular debugging during operation