You start the quarter with 5,000 components to monitor. As the weeks tick off, more and more and more components get monitored. The data in your handheld computers gets uploaded each day.  Your LDAR database recognizes the components that were monitored and they are removed from the schedule.

But some components DON’T get monitored.

As early as the first week of the quarter, the number of “scheduled to be monitored” includes what we call “stragglers:” components that a technician tried to monitor but, for a whole variety of reasons, did not monitor. As the quarter rolls by and each day draws to a close, the number of components that a technician tried, but was unable to monitor grows.

The problem is that the major LDAR Database programs (like LeakDAS, Guideware and FEMS, for instance) do not differentiate between components that are “fresh” (i.e. no one has tried to monitor them) and components that are stragglers (i.e. a technician tried, but was unable to monitor).


The result is that, toward the end of the quarter, a larger and larger proportion of the components “in the schedule” are stragglers. Some have called this the “dregs.” Others, have referred to them as “trash routes.”  Another term is “DTFs” (as in Difficult to Find.)

Perhaps you have heard tales of the legendary LDAR technicians, who could take these trash routes and (by magic, voodoo or exemplary skills and dedication) find and monitor all of the components.

But, the stress can be difficult to absorb and is compounded by the realization that we are going to have to do it all again – next quarter.

Now there is an alternative. It is the result of Bluetooth advances that have made it possible to equip the technicians with handheld computers that are capable of doing more than simply displaying a record of a component to be monitored and then storing the monitoring results.  With the new software that is available, the technicians can give details as to WHY she was unable to complete a component that was scheduled to be monitored. Rather than simply skipping over the components (which tells the database, the site administrator and the next technician that sees this component NOTHING), the technician can provide valuable information about the situation surrounding this component.

There are more the 12 different reasons why a technician might not be able to monitor any given component.  IN EACH AND EVERY CASE, your program objectives of value, integrity and safety are facilitated if and only if you know which of those reasons is true for each component.

IT MATTERS whether the technician did not monitor the component because she couldn’t find it OR if she could find it, but was not able to identify the emission seams on a complicated piece of equipment, for instance.  IT MATTERS that you know that BEFORE you send out the next technician.

We will consider each of the possible scenarios in our next blog and how KNOWING can make a big difference for you and the success of your LDAR program.

In the mean time, check out our new palapa!


0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply