Leak Track 2000
Leak Detection made easy
Frequently Asked Questions
How fast can LT2000 detect a leak?
Leaks are detected using a combination of pressure, flow, line pack and, if available, meter error. For larger leaks, such as a pipeline rupture, leaks can be detected within seconds and verified within minutes.
Can LT2000 detect leaks during an upset?
Yes. During a pipeline upset the metrics (pressures, flows, etc.) in the pipeline oscillate until the pipeline settles into a new equilibrium state. LT2000 takes these oscillations into account based on the type of upset and adjusts internal operating parameters allowing for the variations. Then as the pipeline reaches a new equilibrium state LT2000, continuously readjusts its operating parameters to insure the maximum protection possible.
Are specially trained analysts required to design the system?
No. Because of the way LT2000 monitors for leaks it does not require the complicated and expensive analysis required for many other systems. Pipelines running in mountainous terrain may require additional hydraulic gradient analysis to insure the system is not running in a multi-phase mode.
Can LT2000 help me run my pipeline?
Yes. LT2000's primary purpose is to detect leaks. In order for the best possible leak detection results LT2000 has to know the current state of the pipeline. This information is then passed on to the operator who can use it to improve the operation of the pipeline. This includes information such as batch data, interface arrival alerts and scrapper tracking alerts.
I use a drag reducer is that going to impact performance?
No. The injection of the drag reducer is already taken into account by other parameters.
Will I need to install special hardware?
Most pipelines with SCADA systems, already have the necessary equipment required by LT2000. A simple interface from the SCADA to LT2000 is all that is needed. For systems that support OPC, an optional interface is available.
For pipelines with no telemetry, this will need to be installed. Providing the equipment, typically PLCs, communicates using MODBUS/TCP, a full blown SCADA system is not required. LT2000 supports the MODBUS/TCP interface for accessing and storing data.
How is LT2000 different from a model system?
Leak Track 2000 uses changes to determine a leak instead of a deviation from a model calculation. LT2000 does perform some internal modeling based on the configuration data, not so much to identify leaks but filter out false alarms. The LT2000 methods means less system load, CPU and telemetry, less demand for highly accurate data, and less need high speed telemetry. Yet LT2000 still provides a very reliable leak detection.
An example might be, trying to model how fast a drop of water runs down a window. In a model system you need to know the angle of the window, what contaminants are on the window along the path of the drop, how hot the glass is and if the wind is blowing. Then using well know physical equations simulate the drop, calculating the travel time as the drop slowly makes it way down the window. Then if the arrival time is different from the simulated time, alarm.
With a deviation based process, all we need to know is how long it took for the last drop to travel. If the expected time is different, provided nothing has changed, alarm the change. If something has changed, make allowances based on the amount of change and check the next drop. A much simpler process and yet still highly reliable.
How is LT2000 different from a statistical system?
Leak Track 2000 does not require a statistical history of the pipeline to be operate. Statistical systems require past operational data to be collected, possibly a month or more, before the software can reliably monitor a pipeline. If the pipeline changes or is operated in a new way, it may take time before a statistical system is fully operational.
Using the previous example, a statistical system collects data on valid past operating conditions, recording such information as the glass angle, temperature, etc.. Then using using current conditions, it compares against past data, extrapolating if needed, to calculate an expected drop arrival time. If the drop time is not within expected limits, an alarm is generated.