Pumps & Systems, September 2007
SCADA can be utilized for remote data acquisition, but because it is primarily a real-time control system, the user must make significant compromises to use it for this purpose. These compromises include cost, data integrity, flexibility, convenience and control of the task. Here are some considerations to think through.
A substantial portion of a utility's operation is in the distribution or collection system: pipes, pumps, valves, tanks, meters etc. Utilities have an operational need to know how things are working throughout their system to manage it properly.
In addition to customer usage billing, operational efficiency and maintenance concerns, utilities are driven by tougher government regulations and customer demand for improved quality, safety and security. All of these factors exert pressure on utilities to better understand and document the operation of their network.
Why SCADA
Most utilities employ a SCADA (Supervisory Control and Data Acquisition) system or DCS (Distributed Control System) to operate and monitor their process plants. Extending the SCADA network into the field seems logical and almost obvious if new investment in remote monitoring is required.
A SCADA system requires a huge upfront investment in centralized computer equipment, software, training and personnel time resources to initially implement. Once the utility has sunk this investment, expansion of the system per point is relatively inexpensive, providing additional justification for the initial investment.
Furthermore, the SCADA system manager and operators are reluctant to add alternative systems, particularly if they do not seamlessly integrate with the existing SCADA system they have operating at the plants. SCADA is the safe investment for management reviewing the options; personnel are trained in its use, the utility has committed substantially to its implementation, and it is not something new.
The SCADA argument is compelling and, for many remote sites, it is the best solution - particularly sites that need to be remotely controlled or where real-time mission critical data is required on the big screen in the operations center. For other remote sites where only data acquisition is required, a data acquisition system offers superior cost, reliability and versatility.
System Comparison
Consider first that data acquisition and SCADA systems are architecturally different types of systems.
SCADA is a real-time polling system requiring a continuous channel of communications between the host computer and each remote RTU (remote terminal unit). In data acquisition applications, the RTU responds to requests for real-time measurements from the host computer. If monitoring a field parameter (e.g. flow or pressure) once every five seconds is important, the host computer sends a request for these parameters every five seconds.
SCADA systems operate in this fashion because when performing their primary function, which is control, they make decisions at the host based on real-time data collected from all sensors. However, when a SCADA system is used for data acquisition only, particularly for remote monitoring applications, this approach is not optimum or even practical because of system complexity, cost and data reliability exposure.
A remote DAS (Data Acquisition System), however, is optimized for remote monitoring. A DAS RTU may be independently configured to sample each sensor or instrument at the optimum rate for that parameter. For a flow meter this might be once every second; for sanitary sewer overflow (SSO) level maybe once every 15 seconds.
The DAS RTU, which is fundamentally a data recorder then performs data reduction on these data samples to produce information having optimum value to the user. This might be the total flow at 15-minute intervals, the amplitude and time stamp of water hammer events, or the severity, time of day and duration of a SSO event.
The remote DAS RTU may then upload the resultant information to the host on a programmable schedule and/or on exception as specified by the user. The total amount of data transferred by a DAS compared to SCADA is typically smaller by two orders of magnitude. The communications link is active only occasionally and for short periods: for example, once per day for 30 seconds.
Data Integrity
Data integrity refers to the assurance that the data transmitted from the remote site to the host is not corrupted or lost. A SCADA system can provide perfect data integrity only if and when the host computer is running and the communications channel is functional.
Reality demonstrates that computers crash and remote communication networks fail. Whenever this happens and for the period of time this happens, remote site data sourced by SCADA will be lost forever.
A DAS utilizing RTUs that are data recorders maintains its measured data at the remote site typically for many months, even when data is being transferred frequently to the host. If the communications channel goes down or the host computer crashes, remote data collection continues and is automatically recovered when the computer or network problems are fixed.
The typical SCADA system approach to improve data integrity for remote monitoring is redundancy. The thinking is that by adding redundant communications channels, computers and fault tolerant computer drives, system reliability is improved. This is true of course, but the user ends up purchasing two expensive data acquisition systems instead of one.
Push Not Pull
SCADA systems poll remote sensors, typically at the highest rate necessary to facilitate control loop dynamics or to capture upset events that occasionally occur in the process. This might be a sample rate of every few seconds.
Although necessary for the plant floor environment, where events occur quickly and sensor power and networking access is convenient, real-time information is not often necessary or even appropriate for remotely deployed sensors and instruments.
In most remote monitoring applications, uploading information to the host computer at a rate useful to the user is desirable; this might be every 15 minutes, once per day or on exception. For example, uploading data from a remote rain gauge is only necessary when it is actually raining, or a CSO overflow event when it is overflowing. The pressure history of a remote water main might be useful information daily unless the pressure goes
