When we talk about SCADA troubleshooting, we must consider that SCADA systems are easily classified as one of the greatest data acquisition methods to have ever been invented. The ability to gather data from various distances, translate to a user-friendly format, and combine the points into a viable action plan is extraordinary. These control systems can be as simple as a single remote terminal unit (RTU) pulling a single data point and feeding back to a computer, or as complex as thousands of data points being pulled from a water treatment process. SCADA enables anyone to measure process performance and adjust as necessary.
As with any system, uptime is rarely a 100 percent. The fact that communication across distance is highly susceptible to interference makes the ability to troubleshoot a SCADA system a valuable skill for many companies in countless industries. The following is a very basic process for tracking down issues in SCADA systems. We try to guide our customers to check the easy stuff first. Oftentimes a problem can be solved more quickly and more efficiently by on-site personnel. Sometimes the problem with a SCADA system can be identified just by knowing where to look.
1. Check the HMI
The human machine interface (HMI) can be anything from the display on the front of a control panel to the computer to which the data is fed. Many times a simple setting change can be the issue of a SCADA system not collecting data or not reading properly. Verify that the settings are correct to what the owner needs. Don’t overlook the mundane, but critical, aspects of the HMI: caps lock, number lock, power feeding to the system, etc. Have operators review to confirm that the HMI settings all look the way they usually do.
2. Confirm Communication
The backbone and reason SCADA systems work in the first place is the communication process. Locate where the Ethernet (or other communication) ports are and verify that they are talking through the wire. (This can often be confirmed by a blinking indicator light on the connector itself. If that light is off, no signal is getting through the wire.)
Additionally, take the time to open the control panel to verify that a signal is being sent to the proper places. Are there lights on the controller? Is the programming up to date? Do all of the wires appear to be connected well (no frayed strands, not too many wires on the same contact, etc.)? Are the components on the panel connected to something in the first place? Another step is to verify the correct connections with the “as-shipped” drawings that accompany the control panel.
3. Field Verification
If everything else appears to be in working order, the next step is to make the trip to the data point. This step could be simple or complicated depending on the distance. The easiest (though not always the most practical) way to verify correct readings from instrumentation is to set everything to a zero. For example, if a flow meter is sending the signal of flow from a pump through a controller and into a SCADA system, the easiest way to verify that the readings are correct is to turn off the pump and confirm that the SCADA system also reads zero flow. This step can be very labor-intensive depending on the process so it is best to save this one until the other possible issues have been ruled out.
The particular application and process of a given SCADA system will determine the effectiveness, order, and workability of these steps. This list is not all-inclusive, by any means. However, it does provide a good starting point for people who may not be as intimately familiar with the SCADA system as the original system integrator. In the future, we hope to see issues identified and resolved as quickly as possible so that the data continues to be effectively gathered, measured, and used.