Virtually every industrial facility has some kind of gas detection in place: Millions of portable units are in service, and at least a million points of continuous gas detection have been deployed. However, what is being done with all the data?

The first and most vital use of this data, of course, is to provide instantaneous alarms, and from what I have observed over the past many years, this aspect has been successfully implemented. However, there is more to the story.

The majority of chemical compounds encountered in the workplace have regulatory limits of exposure—based on an 8-hour time-weighted average. Moreover, in many cases, a short-term exposure limit (STEL) based on a 15-minute average is also in place.

Thus, merely sounding instantaneous alarms, and even documenting such events, is not quite enough. A time-history record of exposure is the only way to protect your employees. And, by protecting your employees in this manner, you are protecting your company from frivolous litigation.

We know of several cases where no more than mediocre exposure record-keeping was enough to scare away the plaintiff’s attorneys. But, why settle for mediocre? What you need is good data acquisition.

Data Acquisition/Data Logging

Data acquisition or data logging describes a process whereby information generated by some device (a gas detector in this instance) is stored in a manner allowing for its later retrieval. Although the terms were once interchangeable, these days “data logger” usually refers to a small, portable unit; “data acquisition” usually implies a computer-based system with more elaborate features, and certainly greater storage capacity.

Typically, the information stored in a data logger must be downloaded to a computer, and the accessory software will produce reports, and provide a means to archive the data. A data acquisition system is permanently installed on a host computer, with the data streaming in directly. Generally, various reports are produced automatically, and optionally on demand.

Any data collection system must have a means of interfacing with the measuring device. In portable gas detection instruments provided with built-in data loggers, this is transparent to the user. For self-contained portable data loggers, output from the instruments (usually an analog voltage or current) connects directly to the logger. Contained within the logger is an analog-to-digital (A/D) converter, enabling the data to be stored in a digital format.

For installed continuous gas monitoring systems, output from the instrument—often comprising many detection points and thus many dedicated outputs—is connected to a so-called remote terminal unit, or RTU. RTUs are limited to a certain number of inputs, and it is common for several RTUs to be deployed at strategic locations around the monitored area.

From there, the RTU(s) must communicate back to the host computer, usually via some type of serial protocol (RS232, RS485, RS422, Modbus). Ethernet communications are also available. The A/D conversion takes place within the RTU.

With data streaming back to the logger or acquisition system, one more parameter must be invoked, and that is the sampling rate. Should the incoming data be sampled once per second, or is this too slow? The correct sampling rate is determined by the nature of the process being monitored, along with a little common sense.

In gas detection applications, the data does not usually change rapidly, unless there is an upset condition. Even then, delays of a few seconds would make no difference, especially if an instantaneous alarm is going to sound anyway.

Related to this is the matter of what number (or “argument”) is actually stored. In some systems—including the default setting of Interscan’s Arc-Max®—the data is sampled once per second; what is stored is the one-minute average of these readings. (Alarms are registered at the moment of occurrence.)

Reports

It all comes down to this. Your data acquisition system can have the greatest “under-the-hood” operations, but what you will be dealing with as the end-user are screen and printed reports.

For use with a gas detection system, the minimum requirements for reporting would be:

  • 8-hour time-weighted average continuously updated. This means that the 8-hour average is always presented, even as the exposure period begins.
  • Documentation of instantaneous alarms
  • Documentation of STEL incidents

Desirable optional features would include:

  • Live and historic trending (graphic representations of time history)
  • A “mimic” function, whereby monitoring points are pictorially represented on a screen, and clicking on the pictorial calls up the data for the point in question
  • A facility to separate reports by shift, ideally supporting overlapping shifts, handling at least three shifts per day
  • The ability to export data in various formats

It is highly recommended that the reporting features are included as part of the data acquisition software package. Beware of any vendor who glibly advises you that in lieu of giving you the reports you want, you can “Just export the data to Excel”—or other spreadsheet program. It is by no means easy to create continuously updating reports in this manner.

Putting It All Together

Get all the benefit you can from your gas detection system! Convert that endless stream of data into a tool that can give you a much better handle on employee exposure. Line up the time history data with processes that occur in your plant, and you’ve just changed gas detection from reactive to proactive.

Data Logging and Data Acquisition in Gas Detection
1 vote, 3.00 avg. rating (66% score)