One of the arguments against leak detection has often been, “and the costs go on.” Installing a new system involves some engineering work to figure out what needs to be protected and developing suitable ways of doing so; acquisition of suitable measurement, communications, and processing equipment; installing all this new equipment; training company people or hiring a contractor to take care of it; and periodically monitoring for proper operation. Many of these turn out to be reoccurring costs.

Over time, what seemed to be an expensive system initially produces a substantial stream of continuous costs, much like a DCS or SCADA system does. A leak detection system, though, is safety equipment, almost always mission-critical, and demonstrably necessary to safe and reliable and well as legally viable, operation.

Most information technology departments in major companies have well-developed and experience-based policies that establish guidelines, or even rules, for maintaining the currency and integrity of mission-critical systems. Many such policies involve the periodic replacement of some of the hardware, often at five-year intervals. Some require some sort of redundancy or resource-sharing configuration which can increase the amount of mission-critical equipment because of additional communications requirements, more servers in more places, and more network management software.

Even with insightful configurations and lots of redundancy, unusual failures can develop, some of which can be difficult to identify and diagnose without focused testing procedures. This motivates periodic manual testing or automated test systems. Automated systems usually generate alarms and reports that trained people have to see, read, and understand.

None of this is specific to leak detection – it is a fundamental necessity of living with and benefiting from modern process monitoring and control sophistication. While insightful management can optimize the user effort involved to produce a credible result, there is no way to avoid it.

Hardware and software maintenance are often interlinked. Operating system software may assume or require particular hardware features. Application programs may depend on certain operating system features, or hardware performance (usually represented by processing speed or data storage capacity) in order to work properly.

Sometimes upgrading one or more of the system components discloses incompatibilities resulting from the others. Most IT departments are keenly aware of this and have procedures that avoid unpleasant discoveries and outcomes. Detecting Leaks in Pipelines discusses some of these issues.

In many companies, critical people with positive job records get noticed and promoted. When these people work in IT or in the specialties it supports, they can be sorely missed. It can be hard to find and train suitable replacements. Often there are several levels of training. Some operating systems may be sufficiently evolved to require certification-level augmentation to existing training programs. In some cases, new hires may not come trained on the hardware and software systems you are actually using.

In process control, some of the applications can involve features and tools that are not in the experience of personnel trained on more routine equipment providing more usual application support. Depending on what changes, it’s easy to need a few days of training and often necessary to schedule a week or more. All of this costs something. There are employee expenses, overtime, extra-time, and trainer-time. All of this involves budgeting, scheduling, evaluating, and usually some sort of remedial work.

These cost streams are never “over.” They are only abated until the next issue occurs that forces revisiting them. Most IT departments have developed policies and procedures that establish criteria for the needs and processes for the implementation of this recurrent training. Insightfully done it can increase performance and thereby control or reduce costs, or at least “surprises.” No matter what, though, it is a cost of doing business in the age of information technology and automatic control.

Programs for ongoing support should be envisioned in the beginning, when the applications are being designed and the equipment to implement them selected. There can be benefits from commonality and from an effort to remain in the “mainstream” of the evolution of automation technology. Signing on to be the last user of an obsolete technology can turn out to not only be expensive but very frustrating. Anticipating the evolution of the technology can keep budgets in control and reliability high for long periods of the evolution we all see and hope to cope with.

When I was in college there was a story intended to motivate engineering students to learn to think ahead. It involved a long dialog about a factory assembling a new large aircraft design and the angst a supervisor kept feeling when he went to the place where the wings were being assembled, with a huge pattern of carefully arranged attachment bolt locations.

A time later this same person would visit the factory location where the fuselage was being built and his eyes would pass over the huge pattern of carefully arranged fuselage attachment bolt locations. Finally, one day, the wings were brought to the fuselage, hoisted into place and a crew took position to insert the hundred or so bolts involved in fastening it all together.

What do you suppose happened next? Could it have been avoided with a little more organization, planning, care, structure, or any of those ideas management books and plans dwell over?

Over time, support can be as important as the selection and implementation of the original system. It isn’t an extra cost. It’s the inherent price of using this kind of technology.